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

файловые системы 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) может быть трудно работать с каталогами, в которых слишком много файлов. Таким образом, рекомендуется разделить ваши файлы так, чтобы у вас не было более нескольких сотен или тысяч элементов в любом заданном каталоге. Простой способ сделать это — хешировать любой идентификатор, который вы используете, и использовать первые несколько шестнадцатеричных цифр в качестве промежуточных каталогов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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