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

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

Меня беспокоит то, что сразу будет 20000 предметов, что означает примерно 60000 изображений.

Вопросы:

Какое максимальное количество файлов и/или каталогов в Linux?
Как обычно справляться с этой ситуацией (лучшая практика)?

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Как правило, это делается следующим образом:

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

md5($id) ==> 0123456789ABCDEF

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

1 node = 4096 subnodes (fast)