Размер директорий не стоит наших усилий

[osipov_dv]

Во-первых вы создали не миллион файлов, а на порядок меньше. Во-вторых, хотелось бы знать, что скажет du на ту же директорию?

[sledopit]

«Миллион» я больше употребил в переносном значении «очень много». Смысл от этого не сильно меняется. du показывает те же 8.1М, что и ls -ld.

[rboots]

Честный миллион файлов сгенерировался у меня за 11 минут 51 секунду и занял 31 мегабайт.

[maxzhurkin]

А удалялся как долго?

[homm]

Если создавать не из баша, а хотя бы из питона, то создается за ≈30 секунд, удаляется за ≈17. ext4

[tmin10]

Можно просто выкачать какой-то пакетик из npm и вуаля — миллионы js файликов с функциями типа left-pad.

[Sly_tom_cat]

А вы не используйте всякие ext4 с внутренней архитектурой унаследованной от древней как гавно мамонта ext2.
Пользуйтесь нормальными ФС где indode аллокируются динамически, а не так как у extX приколочены гвоздями в группам распределения и выделяются при первичном форматировании и больше — ни ни.

[Sly_tom_cat]

ZFS же

[click0]

Нехватка inode была на UFS/UFS2.
С Zfs, как и со многими FS другая проблема — при заполнении раздела на >95% происходит деградация производительности.

[maxzhurkin]

Простите за некропостинг:
В UFS inode создаются при форматировании, фиксированное количество, в то время как в UFS2 они создаются динамически по мере необходимости, так что вы правы только наполовину

[Sly_tom_cat]

Минусатора прошу пояснить: что именно не понравилось в моем сообщении, или может я где-то неправду сказал?

[maxzhurkin]

Минусатор, возможно, не получил уведомления о вашем комментарии, а если бы и получил, то наверняка, не передумал бы, а вот ваше «я Д'Артаньян, а вы деритесь в открытую, а не как трус» мало кто способен оценить в вашу пользу.

P.S. Не благодарите

[click0]

EXT4 и ZFS, если осилите установку или миграцию.

[engine9]

Посоветуйте правильных же!

[Pyhesty]

о! как раз хотел узнать об ограничении на количество файлов в директории в разных FAT? а для fat32 и ntfs, ограничения какие-то накладывают на кол-во файлов в каталоге?

[black_semargl]

В fat16 корневая директория фиксированного размера. Остальные — просто файлы со специальным атрибутом, произвольного размера
В fat32 корень вообще из одного элемента, указывающего на файл корневой директории.
В ntfs примерно так же, только «базовых файлов» там несколько — и корневая директория, и таблица занятости, и т.д. И мелкие файлы могут быть размещены прямо как поле данных в каталоге, рядом с именем.

[black_semargl]

А вот и нет — первый кластер корневой директории прописан в первом секторе по смещению 0х2С.
После форматирования это действительно 2, но вот после дефрагментации может быть по-разному

[black_semargl]

Некоторые — да. Как собственно дефрагментировать эту корневую директорию, кроме как переместив её на свободное место?

[geher]

В FAT установлен предел 65535 запией. Поичем первые две заняты точкой (ссылка на себя) и двумя точками (ссылка наверх).
Если используются длинные имена (в формате, отличном от 8.3), то будет еще меньше (каждое длинное имя "крадет" несколько записей).

.

[DistortNeo]

В интернетах пишут, что для NTFS — 2^32-1 файлов, а для FAT32 размер директории ограничен реализацией — 2 мегабайта, что соответствует 64K записям формата 8.3. В случае использования длинных имён инфа от имени размещается в этих записях, по 13 символов на запись. В случае использования длинных имён может использоваться до 20 записей на один файл +1 вхождение для формата 8.3, что в итоге приводит к 3120 файлам с именами 255-байтной длины.

[VolCh]

В случае какого-нибудь докера или chroot плюс node_modules :) вполне могут привести к переполнению 255 символов полного пути. И изнутри виртуальной ФС далеко не всегда легко понять, что происходит.

[iig]

Кроме того, в fat директория это линейный список; время доступа к файлу очень сильно зависит от его размера. 65533 файлов в директории — чистое зло.

[berez]

Ну как бы да. И что?
В директории имена файлов идут списком — и если какой-то файл удален, то запись о нем просто помечается как пустая. Иначе для больших директорий на каждое удаление пришлось бы менять все содержимое директории — а это повышенная нагрузка на кэши и всякое такое.

И кстати, линукс тут неуиноуат — в винде точно такая же проблема.

Интересно было бы поиграться с различными файловыми системами, где имена файлов в директориях хранятся не списком, а в виде двоичного дерева (btrfs вроде такая).

[Sly_tom_cat]

Btrfs:
$ mkdir niceDir && cd niceDir
$ ls -lhd.
drwxrwxr-x 1 stc stc 0 авг 2 18:22.
$ for ((i=1;i<133700;i++)); do touch long_long_looong_man_sakeru_$i; done
$ ls -lhd.
drwxrwxr-x 1 stc stc 8,5M авг 2 18:21.
$ find. -type f -delete
$ ls -l
total 0
$ ls -lhd.
drwxrwxr-x 1 stc stc 0 авг 2 18:22.

В Btrfs пустой каталог 0, после очистки каталога — тоже 0.
С b-tree при удалении нет смысла оставлять блоки, которые больше не используются — они все уходят в свободные.

XFS:
$ mkdir niceDir && cd niceDir
$ ls -lhd.
drwxrwxr-x 2 stc stc 6 авг 2 18:42.
$for ((i=1;i<133700;i++)); do touch long_long_looong_man_sakeru_$i; done
$ ls -lhd.
drwxrwxr-x 2 stc stc 6,2M авг 2 18:47.
$ find. -type f -delete
$ ls -lhd.
drwxrwxr-x 2 stc stc 6 авг 2 18:47.

Примерно так же.

[xsevenbeta]

reiserfs, живой сервер:
adminx@xxxx:/informatica_cache/SessLogs> ls -ldh
drwxr-xr-x 5 adminx etl 85M Aug 5 07:53.

adminx@xxxx:/informatica_cache/SessLogs> ls -l | grep -c ""
970181

ls -1 >> ~/filelist
adminx@xxxx:/informatica_cache/SessLogs> ls -lath ~/filelist
-rw-r--r-- 1 adminx etl 68M Aug 5 07:58 /home/adminx/filelist

Тут конечно больше интересно, как большое количество файлов влияет на производительность при чтении/создании/изменении файла.

[manefesto]

Экономически не выгодно :)

[stetzen]

Лень проверять — означает ли такое поведение, что если внутри директории постоянно создавать и удалять файлы, её размер будет постепенно пухнуть? Если да (а кажется что должно), то в принципе на каких-то крайне тощих устройствах это может стать проблемой, если эту штуку не учесть.

[sledopit]

Нет. В этом случае оно просто переиспользует освобожденное место и всё будет хорошо.

[arheops]

Нет, потому что такое поведение — типично, например, для /var/log/ или /var/spool/mail. Тоесть оно бы сильно мешало работать.
Потому переиспользование записей — выполняется, а вот их освобождение — нет. Никому не нужно ибо. Если у вас в директории было 500тыс файлов, значит, вполне вероятно, скоро опять будет столько же. Тоесть нет смысла освобождать.

[Sly_tom_cat]

Ну не стоит так категорично…

Если каталог лежит в b-tree, то смысла как-то искусственно сохранять выделенные блоки, которые уже не используется деревом — нет. И например (см. выше) btrfs и xfs после удаления таки все освобождают.

[arheops]

У XFS свои приколы. Я за последние полгода два раза перегружал прод, ибо оно вродекак и освобождает, но не сейчас и места нету.

[Sly_tom_cat]

Там типа GC (в Python/Go/Java и т.п.) — очень много всего на потом откладывается. И в кеши, в кеши, в кеши. XFS очень сильно кеши любит… порой излишне…
Но зато на том же тесте с заполнением каталогов она у меня сделала btrfs на том же диске:

btrfs:
$ time for ((i=1;i<133700;i++)); do touch long_long_looong_man_sakeru_$i; done
real 3m29,141s
user 2m22,319s
sys 1m24,666s

xfs:
$ time for ((i=1;i<133700;i++)); do touch long_long_looong_man_sakeru_$i; done
real 3m23,376s
user 2m20,233s
sys 1m19,493s

И это при том что btrfs тоже изрядно все кеширует, но все-же не так агрессивно как xfs.

[xsevenbeta]

Может, имеет место быть ситуация когда удаляют кем-то занятый файл? В таком случае в файловой системе файла видно уже не будет, а место на диске будет отсутствовать. Увидеть удалённый файл, который занимает место можно по lsof.

[arheops]

Ну там файлы были mysql binary logs и mysql точно был перезапущен.
Такчто нет.

[engine9]

Т.е. это не баг а фича, и нет нужды прогонять fsck?

[arheops]

Можно починить, можно.
Сначала делаете rsync в другую дерикторию, потом меняете названия и удаляете старую.
И не надо ничего отмонтировать.
Ну, наверно можно то же самое сделать и внутри FS, но как правильно написали в мейлисте никому это не нужно по сути. А этот код потом поддерживать.
Можно написать внешнюю утилиту. Которая сначала скопирует содержание всех блоков в другую директорию, потом эту удалит и переименует. Но возникает вопрос с файлами открытыми приложениями в данный момент.

[arheops]

Можно наверно. Просто у меня обычно после удаления файлов немного.
А разве на жесткие ссылки нет ограничений? вроде на каталог не может указывать, не?

[black_semargl]

Создать правильными методами нельзя. Но "." и ".." — это именно хардлинки.

[khim]

Да, но нет. На самом деле "." и ".." в Linux — чисто виртуальная конструкция, с диска ничего не читается и не пишется.

Что приводит к забавному эффекту: если вы на флешке (то бишь FAT) создаёте каталог, то Linux занесёт дату создания в элементы "." и ".." в этом каталоге — а изменить это будет невозможно никак, в принципе.

То есть, в частности, воспользовавшись советом arheops вы внесёте изменение, которое потом будет видно из-под Windows… несмотря на то, что rsync, вроде как старается даты модификаций файлов и все аттрибуты сохранять.

[black_semargl]

Разве? Вроде именно потому нельзя хардлинки на каталоги, что они используются для внутренней связности (т.е. прописывается ссылка на номер своего инода и инода вышестояшего)

[Harbour]

проблема высосана из пальца:

a) создаем миллион файлов и плачем о потерянных 8Mb
b) хотим миллион файлов но не заботимся об оптимизации и регулярном fsck