Максимален брой файлове/директории в Linux?

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

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

Няма ограничение за директориите извън това; имайте предвид, че всеки файл или директория изисква поне един блок на файловата система (обикновено 4KB), дори ако това е директория само с един елемент в нея.

Както можете да видите обаче, 80 000 inode е малко вероятно да са проблем. И с опцията dir_index (активирана с tune2fs), търсенията в големи директории не са голяма работа. Имайте предвид обаче, че много административни инструменти (като ls или rm) могат да имат затруднения при работа с директории с твърде много файлове в тях. Поради това се препоръчва да разделите вашите файлове, така че да нямате повече от няколкостотин до хиляда елемента във всяка дадена директория. Лесен начин да направите това е да хеширате какъвто и да е идентификатор, който използвате, и да използвате първите няколко шестнадесетични цифри като междинни директории.

Например, кажете, че имате ID на елемент 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 е достатъчно лесен механизъм за определяне коя директория да използвате.)

60 000 са нищо, 20 000 също. Но трябва да групирате тези 20 000 по всякакъв начин, за да ускорите достъпа до тях. Може би в групи от 100 или 1000, като вземете номера на указателя и го разделите на 100, 500, 1000, каквото и да е.

Например, имам проект, в който файловете имат номера. Групирам ги в 1000, така че имам

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

Всъщност може да имате твърдо ограничение - някои системи имат 32-битови inodes, така че сте ограничени до брой от 2^32 на файлова система.

В допълнение към общите отговори (основно „не се притеснявайте толкова много“ и „настройте вашата файлова система“ и „организирайте вашата директория с поддиректории, съдържащи няколко хиляди файла всяка“):

Ако отделните изображения са малки (напр. по-малко от няколко килобайта), вместо да ги поставите в папка, можете също да ги поставите в база данни (напр. с MySQL като BLOB) или може би вътре в GDBM индексиран файл. Тогава всеки малък елемент няма да консумира inode (на много файлови системи всеки inode иска поне няколко килобайта). Можете също така да направите това за някакъв праг (напр. да поставите изображения, по-големи от 4kbytes в отделни файлове, и по-малки в база данни или GDBM файл). Разбира се, не забравяйте да архивирате вашите данни (и да дефинирате стратегия за архивиране).

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

Надявам се това да помогне на някой да вземе решение от всички алтернативи.