Максимальное количество файлов в каталоге в ext4

Я управляю приложением, которое содержит хранилище файлов, в котором хранятся все файлы с именами файлов, равными их суммам md5. Все файлы хранятся в одном каталоге. В настоящее время существуют тысячи, но скоро их должно быть на сервере миллионы файлов. Текущий сервер работает под управлением Ubuntu 11.10 в файловой системе ext4.

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

Это все еще правда, или у современных файловых систем (например, ext4) есть более эффективные способы справиться с этим и естественно масштабировать? В Википедии есть некоторые подробности о файловых системах, но на самом деле ничего не говорится о максимальном количестве файлов в каталоге или времени поиска.

В ext3и более поздних версиях файловых систем поддерживают хэш - B-дерево индексации каталогов. Это очень хорошо масштабируется до тех пор, пока вы выполняете только операции добавления, удаления и доступа по имени. Тем не менее, я все равно рекомендую сломать каталоги. В противном случае, вы создаете опасную ловушку для инструментов ( updatedb, ls, duи так далее) , которые выполняют другие операции над каталогами , которые могут взорвать , если каталог имеет слишком много записей.

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

Как это случилось, я столкнулся с точно такой же проблемой в нашей собственной разработке (md5sum в качестве имени файла, его масштабирование). То, что я рекомендовал нашим разработчикам, это нарезать строку на кусочки. Они работали с группами по 4 человека, но в файловой системе, в которой мы были в то время, даже многие из них оказались бы проблематичными с точки зрения производительности, поэтому они в итоге разделились на группу из 3 для первых 6 триплетов и оставили остальные как имя файла в каталоге терминала.

Группа 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Группа 3:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Преимущество заключается в том, что размер каталогов остается небольшим, а поскольку MD5sum довольно случайный, он создает сбалансированные деревья каталогов. Этот последний каталог вряд ли когда-либо получит больше, чем несколько файлов. И не было так сложно работать в нашем коде. Мы работаем с многомиллионными файловыми проектами, поэтому масштабирование было для нас очень важно.

Современные файловые системы очень хорошо справляются с очень большими каталогами, даже с миллионами файлов. Но обычных инструментов нет. Например, перечисление такого большого каталога с помощью «ls» займет довольно много времени, так как обычно он читает весь каталог и сортирует его (хотя вы можете использовать ls -f, чтобы избежать сортировки). Он не начнет показывать файлы, пока все не будет прочитано. Разделение имен помогает в некоторых случаях, но не во всех (например, для репликации rsync может потребоваться собрать все дерево имен).

Могу ли я предложить вместо этого использовать базу данных SQL? Это, вероятно, превратит эту слабость в вашем приложении в силу.