Максимальное количество файлов/папок в Linux?

Я разрабатываю интернет-магазин LAMP, который позволит администратору загружать несколько изображений для каждого элемента.

моя забота - сразу же будет 20000 элементов, означающих примерно 60000 изображений.

вопросы:

  1. каково максимальное количество файлов и / или папок в Linux?

  2. каков обычный способ справиться с этой ситуацией (лучшая практика)?

моя идея состояла в том, чтобы сделать папка для каждого элемента, на основе его уникального идентификатора, но тогда у меня все равно будет 20000 папок в main передает папка, и она будет расти бесконечно, поскольку старые элементы не будут удалены.

Спасибо за любую помощь.

6 ответов


ext[234] файловые системы имеют фиксированное максимальное количество индексов; для каждого файла или каталога требуется один индекс. Вы можете увидеть текущее количество и ограничения с помощью df -i. Например, в файловой системе 15GB ext3, созданной с настройками по умолчанию:

Filesystem           Inodes  IUsed   IFree IUse% Mounted on
/dev/xvda           1933312 134815 1798497    7% /

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

как вы можете видеть, хотя, 80,000 inodes вряд ли будет проблемой. И с dir_index вариант (enablable с tune2fs), поиске в больших каталогах не слишком большое дело. Однако обратите внимание, что многие административные инструменты (например,ls или rm) может иметь трудное время работы с каталогами со слишком большим количеством файлов в них. Таким образом, рекомендуется разделить ваши файлы так, чтобы у вас не было более нескольких сотен до тысячи элементов в любом каталоге. - простой способ сделать это хэш какой код вы используете, и использовать первые несколько шестнадцатеричных цифр в качестве промежуточных каталогов.

например, скажем, у вас есть идентификатор элемента 12345, и он хэшируется до 'DEADBEEF02842.......'. Вы можете хранить свои файлы в разделе /storage/root/d/e/12345. Теперь вы сократили количество файлов в каждом каталоге на 1/256.


если файловая система сервера имеет dir_index функция включена (см. tune2fs(8) для получения подробной информации о проверке и включении функции), то вы можете разумно хранить более 100 000 файлов в каталоге до снижения производительности. (dir_index был по умолчанию для новых файловых систем для большинства дистрибутивов в течение нескольких лет, поэтому это будет только старый файловая система, которая не имеет эту функцию по умолчанию.)

это сказало, добавив еще один уровень каталога, чтобы уменьшить количество файлов в каталоге в 16 или 256 раз, резко повысит вероятность таких вещей, как ls * Работа без перезапуска ядра maximum argv размер.

как правило, это делается примерно так:

/a/a1111
/a/a1112
...
/b/b1111
...
/c/c6565
...

т. е., добавляя букву или цифру к пути, на основе некоторой функции вы можете вычислить имя. (Первые два символа md5sum или sha1sum имени файла является одним из распространенных подходов, но если у вас есть уникальные идентификаторы объектов, то 'a'+ id % 16 это достаточно простой механизм, чтобы определить, какой каталог использовать.)


60000 ничего, 20000 также. Но вы должны поставить группу этих 20000 любыми средствами, чтобы ускорить доступ к ним. Может быть, в группах по 100 или 1000, взяв номер каталога и разделив его на 100, 500, 1000, что угодно.

например, У меня есть проект, где файлы имеют номера. Я группирую их в 1000s, поэтому у меня есть

id/1/1332
id/3/3256
id/12/12334
id/350/350934

на самом деле у вас может быть жесткий предел - некоторые системы имеют 32-битные индексы, поэтому вы ограничены числом 2^32 в файловая система.


в дополнение к общим ответам (в основном "не беспокойтесь так много", и "настройте свою файловую систему", и"организуйте свой каталог с подкаталогами, содержащими несколько тысяч файлов каждый"):

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


2014 год. Я возвращаюсь вовремя, чтобы добавить этот ответ. Много больших/маленьких файлов? Вы можете использовать Amazon S3 и другие альтернативы на основе Ceph, такие как DreamObjects, где нет ограничений каталога, о которых нужно беспокоиться.

Я надеюсь, это поможет кому-то решить из всех альтернатив.


md5($id) ==> 0123456789ABCDEF

$file_path = items/012/345/678/9AB/CDE/F.jpg 

1 node = 4096 subnodes (fast)