Много файлов в папке

Есть информация, что на NTFS все работает нормально при 25 млн. файлов в папке

охотно верим, бгг

reiserfs чем не нравится?

reiserfs вроде стандартом не идет, там какая то версия древняя. надо будет на продакшене с бубном танцевать, стремно запороть все. работает не трогай как говорят. просто хочу узнать ext4 потянет? кто сталкивался?

ssd

какая то версия древняя

Нормальная версия. УМВР. Зато не эти помои extX.

то кончаться иноды

Задай при создании их кол-во с запасом.

С какой целью интересуешься?

никакая не древняя.
ты думаешь всё новое лучше?
а экст...можно при создании задать инодов по-больше

надо будет на продакшене с бубном танцевать

чего?

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

Та ну его в инод! Пущай vfat ставит, раз ССЗБ такой!

Если создать на ext4 файл с raiserfs и примонтировать куда нужно, так можно? не закончатся иноды?

Ну что за извращение? Отформатируй уже раздел по-человечески. А так — ну, будет у тебя тупить, как собака, т.к. 2ФС.

Если уж делать нефиг и хочется на свою пятую точку приключений, переформатируй в ext4 с увеличенным количеством инодов.

для начала надо бы df -i посмотреть, а то советуете не глядя.

Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb 61046784 8198556 52848228 14% /var/www

дык, ЛОР же!

заполнишь почти 53 млн. файлов приходи

Если файлы 3-6 кб, то наверное рациональнее было создавать фс с параметром mkfs.ext4 -i 4096 /dev/sdx , так на одну иноду будет приходиться 4096 байт (по дефалту 16, в /etc/mke2fs.conf записано), потери были бы наверное значительно меньше (может вдвое, если распределение равномерное). Если распределение равномерное между 3 и 6 кб, то ориентировочно иноды закончатся примерно на 31% места ( средний размер файла = (3+6)/2 = 5кб, 5/16 = 0,3125 - отношение занятого места к всему месту на диске)

Если бы фс была создана с параметром -i 4096 то при том же распределении размера файлов место бы закончилось где-то 71,4%

Считал так.

1) Файлы от 3х до 4х кб влезают в иноду, это четверть от всех файлов (предполагая равномерное распределение).

2) Файлы от 4х кб до 6кб, влезают в одну иноду полностью и одну иноду заполняют в среднем на четверть, это 75% от всех файлов.

Итого:
1) 25% раздела заполенны точно.
2) 75% раздела на половину заполнены, т.е. ещё 37,5% от раздела заполнены.
3) и 35.5% раздела заполнены на четверть, т.е. 35.5%/4 = 8,875% от раздела.

Значит заполнятся 25 + 37,5 + 8,875 = 71,375% раздела, что несколько лучше чем 31%.

Говорят что reiserfs (или reiser4, не уверен) относится к месту на диске гораздо лучше, потому что умеет паковать концы файлов прямо в иноду. Поэтому при большом кол-ве мелких файлов я бы попробовал её, если сильно не устраивают получившиеся цифры.

спасибо за подробную инфу!

а можно df -h ради любопытсва (чтобы поглядеть какая заполненность места по отношению к заполненности инод)?

Filesystem Size Used Avail Use% Mounted on

/dev/sdb 917G 116G 755G 14% /var/www

как то странно получается у тебя

Инод 14% занято и места 14%. выходит место закончится на 100% раздела. То ли файлы в среднем по 16к, то ли на разделе ещё что-то есть кроме этих файлов.

есть ли на разделе что-то кроме файлов 3-6к ?

Да, кроме файлов ещё информация есть, но мелких файлов вроде большинство. Сейчас посмотрел, размер 4-30 кб., ошибся немного. Буду мониторить свободное место и иноды.

И ещё такой вопрос, не подскажите, время доступа к файлу может измениться от заполненности папки?

Например, сейчас в /folder/ - 100к файлов, если будет увеличение до 1 млн, время может резко возрасти?

time cat /var/www/......../folder/80e0a1a18c9e126a068d6090131ed8d3 real 0m0.002s user 0m0.001s sys 0m0.001s

reiserfs чем не нравится?

На 100к файлов в одной директории могут быть значительные подтормаживания. На миллионе становится совсем неуютно.

/var/www/......../folder/80e0a1a18c9e126a068d6090131ed8d3

Часто для уменьшения числа файлов в одной директории делают так: folder/80/e0/a1a18c9e126a068d6090131ed8d3, уменьшая в среднем число файлов в одной директории в 64k раз.

Для малых файлов — ОК,

От размера файлов не зависит, тут дело в структуре директории. Она хранится в виде сортированного списка, и добавление файлов вызывает перезаписывание директории целиком. Если ты имел в виду упаковку мелких файлов, то тут ещё хуже, потому что увеличивает объём дерева.

http://habrahabr.ru/post/157613/ и http://habrahabr.ru/post/152193/ - просвещайся, может понадобиться

Сейчас посмотрел, размер 4-30 кб., ошибся немного.

для 4-30 как посчитать соотношение занятого места и занятых инод я на вскидку не скажу (нужно как то или интеграл брать или бить интервал на много частей, что нудновато делать руками). Но можно смело предполагать что при равномерном распределении -i 4096 даст значительно лучшие результаты и для 4-30 тоже. ввиду того что файлы очень малы (всего в 2 иноды укладывается). будет возможность - пересоздай фс с -i 4096

И ещё такой вопрос, не подскажите, время доступа к файлу может измениться от заполненности папки?

по поводу скорости - обычно при создании фс по умолчанию используется фича dir_index. При использовании этой фичи время почти не возрастёт. Погляди в /etc/mke2fs.conf есть ли в строчке с base_features = параметр dir_index. Если есть - время почти не возрастёт (в centos/rhel и убунту такой параметр есть по умолчанию).

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

кмк данное действо было актуально для ext3 у которой был список вместо хеша. вот там должно было тормозить (и кмк я даже помню это).

UPD - там хеш-три какое-то, не знаю как это, но «хэш» как бы намекает на время не сильно отличающееся от константного. пойду погляжу..

Она хранится в виде сортированного списка

Ты открыл мне новые факты о reiserfs. Неужели там все так черезжопно?

хотя вот тут пишут http://habrahabr.ru/post/157613/ что появлялись рандомные задержки и т.п. при создании файлов на екст4 в плоской директории. наверное есть смысл делать не плоскую структуру, а с поддиректориями.

если структура хешевая то не пофиг ли?

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

время серьёзно различаться не будет.

Наверное, имеешь в виду доступ? Доступ (поиск файла по имени) быстрый, да. Но я говорил о добавлении и удалении файлов в директории. Эта операция у всех тормозит. Не уверен, что обновлять упорядоченную кучу на диске будет быстрее чем прочитать-отсортировать-записать. Особенно на небольших директориях, которых большинство.

Ты открыл мне новые факты о reiserfs. Неужели там все так черезжопно?

Теория иногда разбивается о реальность с её кэшами и медленными носителями, у которых последовательный доступ быстрее случайного, и умные алгоритмы проигрывают глупым.

А когда в будущем появятся диски с SMR, ситуация станет ещё более чудаковатой.

Наверное, имеешь в виду доступ?

да-да, ты прав. про добавление/удаление я как то сразу не подумал. Согласен, поддиректории лучше в любом случае. + это более переносимый вариант (между разными фс у которых может сильно различаться производительность работы с большими плоскими каталогами).

Не, ты насичет сортированного списка скажи: данунафиг!

Не, ты насичет сортированного списка скажи

http://web.archive.org/web/20120722020028/http://homes.cerias.purdue.edu/~flo...

Ищи «Directory Items».

 Files (direct and indirect items) and directories always start with an offset of 1 so that they are sorted behind the stat item in the leaf nodes

Или таки я чего-то не понимаю, или таки переводили с китайского через зулусский...

Наверное, надо было сказать: «ищи заголовок Directory Items».

Дерево в reiserfs — это дерево метаданных, оно не совпадает с деревом директорий. В листьях дерева хранятся элементы разных типов. Stat, directory, direct, и indirect items. В directory items хранятся идентификаторы файлов и их имена. В stat items хранятся времена создания, доступа, изменения и тому подобное.

Да, но я не нашел по поводу сортировки непосредственно в хранилище.

сортировки непосредственно в хранилище

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/reise...

Сейчас файлов в одной папке 100к

В мамку их перенеси, вендузоид.