Имеет ли значение, сколько файлов я храню в одном каталоге? Если так, сколько файлов в каталоге слишком много, и каково влияние наличия слишком большого количества файлов? (Это на сервере Linux.)

Фон: у меня есть веб-сайт фотоальбома, и каждое загруженное изображение переименовывается в 8-шестнадцатеричный идентификатор (скажем, a58f375c.jpg). Это делается для того, чтобы избежать конфликтов имен файлов (например, если загружено много файлов «IMG0001.JPG»). Исходное имя файла и любые полезные метаданные хранятся в базе данных. Прямо сейчас у меня есть около 1500 файлов в каталоге изображений. Это делает перечисление файлов в каталоге (через FTP или SSH-клиент) за несколько секунд. Но я не вижу, что это имеет какое-либо влияние, кроме этого. В частности, похоже, что скорость передачи файла изображения пользователю не влияет.

Я думал об уменьшении количества изображений, создав 16 подкаталогов: 0-9 и af. Затем я переместил бы изображения в подкаталоги, основываясь на том, какой была первая шестнадцатеричная цифра имени файла. Но я не уверен, что для этого есть какая-либо причина, кроме случайного просмотра каталога через FTP / SSH.

FAT32 :

• Максимальное количество файлов: 268 173 300
• Максимальное количество файлов в каталоге: 2 ¹⁶  - 1 (65 535)
• Максимальный размер файла: 2 ГиБ - 1 без LFS , 4 ГиБ - 1 с

NTFS :

• Максимальное количество файлов: 2 ³²  - 1 (4 294 967 295)
• Максимальный размер файла
  • Реализация: 2 ⁴⁴  - 2 ⁶ байтов (16 TiB - 64 KiB)
  • Теоретический: 2 ⁶⁴  - 2 ⁶ байтов (16 EiB - 64 КиБ)
• Максимальный размер тома
  • Реализация: 2 ³²  - 1 кластер (256 ТиБ - 64 КиБ)
  • Теоретически: 2 ⁶⁴  - 1 кластера (1 Yi - 64 КиБ)

ext2 :

• Максимальное количество файлов: 10 ¹⁸
• Максимальное количество файлов в каталоге: ~ 1,3 × 10 ²⁰ (проблемы с производительностью после 10 000)
• Максимальный размер файла
  • 16 ГиБ (размер блока 1 КиБ)
  • 256 ГиБ (размер блока 2 КиБ)
  • 2 TiB (размер блока 4 КиБ)
  • 2 TiB (размер блока 8 КиБ)
• Максимальный размер тома
  • 4 TiB (размер блока 1 КиБ)
  • 8 ТиБ (размер блока 2 КиБ)
  • 16 ТиБ (размер блока 4 КиБ)
  • 32 ТиБ (размер блока 8 КиБ)

ext3 :

• Максимальное количество файлов: min (volumeSize / 2 ¹³ , numberOfBlocks)
• Максимальный размер файла: такой же, как у ext2
• Максимальный размер тома: такой же, как у ext2

ext4 :

• Максимальное количество файлов: 2 ³²  - 1 (4 294 967 295)
• Максимальное количество файлов в каталоге: не ограничено
• Максимальный размер файла: 2 ⁴⁴  - 1 байт (16 ТиБ - 1)
• Максимальный размер тома: 2 ⁴⁸  - 1 байт (256 ТиБ - 1)

У меня было более 8 миллионов файлов в одном каталоге ext3. libc, readdir()который используется find,ls и большинство других методов, обсуждаемых в этом потоке, для вывода больших каталогов.

Причина lsи findмедленная в этом случае в том, что за readdir()один раз считывает только 32 КБ записей каталога, поэтому на медленных дисках для просмотра каталога потребуется много операций чтения. Существует решение этой проблемы со скоростью. Я написал довольно подробную статью об этом по адресу: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- л.с. /

Ключ к выводу: используйте getdents()напрямую - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html, а не все, что основано на libc, readdir()так что вы можете указать буфер размер при чтении записей каталога с диска.

У меня есть каталог с 88 914 файлами в нем. Как и вы, это используется для хранения миниатюр и на сервере Linux.

Перечисленные файлы через FTP или php работают медленно, да, но при отображении файла также наблюдается снижение производительности. например, www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg имеет время ожидания 200-400 мс. Для сравнения на другом сайте у меня есть около 100 файлов в каталоге, изображение отображается после всего лишь ~ 40 мс ожидания.

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

Это немного зависит от конкретной файловой системы, используемой на сервере Linux. В настоящее время по умолчанию используется ext3 с dir_index, что делает поиск больших каталогов очень быстрым.

Так что скорость не должна быть проблемой, кроме той, которую вы уже отметили, а именно то, что списки займут больше времени.

Существует ограничение на общее количество файлов в одном каталоге. Кажется, я помню, что он определенно работал до 32000 файлов.

Имейте в виду, что в Linux, если у вас есть каталог со слишком большим количеством файлов, оболочка может не иметь возможности использовать подстановочные знаки. У меня есть эта проблема с фотоальбомом, размещенным на Linux. Он хранит все изображения с измененным размером в одном каталоге. Хотя файловая система может обрабатывать много файлов, оболочка не может. Пример:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

или

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

Я сейчас работаю над похожей проблемой. У нас есть иерархическая структура каталогов и мы используем идентификаторы изображений в качестве имен файлов. Например, изображение с id=1234567находится в

..../45/67/1234567_<...>.jpg

используя последние 4 цифры, чтобы определить, куда идет файл.

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

Что бы это ни стоило, я просто создал каталог в ext4файловой системе с 1 000 000 файлов в нем, а затем произвольно получил доступ к этим файлам через веб-сервер. Я не заметил никакой премии за доступ к тем, у кого, скажем, всего 10 файлов.

Это радикально отличается от моего опыта, который я делал ntfsнесколько лет назад.

Самая большая проблема, с которой я столкнулся, связана с 32-битной системой. Как только вы передадите определенное число, такие инструменты, как 'ls', перестанут работать.

Попытка что-либо сделать с этим каталогом, когда вы преодолеете этот барьер, становится огромной проблемой.

У меня была такая же проблема. Попытка сохранить миллионы файлов на сервере Ubuntu в ext4. Закончились мои собственные тесты. Выяснилось, что плоский каталог работает намного лучше, но при этом гораздо проще в использовании:

Написал статью .

Если время, необходимое для реализации схемы разбиения каталогов, минимально, я за это. В первый раз вам придется отладить проблему, которая включает в себя манипулирование каталогом из 10000 файлов через консоль, которую вы поймете.

Например, F-Spot хранит файлы фотографий в формате YYYY \ MM \ DD \ filename.ext, что означает, что самый большой каталог, с которым мне приходилось иметь дело при манипулировании моей коллекцией ~ 20000 фотографий, составляет около 800 файлов. Это также делает файлы более легкими для просмотра из стороннего приложения. Никогда не думайте, что ваше программное обеспечение - единственное, что будет иметь доступ к файлам вашего программного обеспечения.

Это абсолютно зависит от файловой системы. Многие современные файловые системы используют приличные структуры данных для хранения содержимого каталогов, но старые файловые системы часто просто добавляли записи в список, поэтому получение файла было операцией O (n).

Даже если файловая система делает это правильно, программы, перечисляющие содержимое каталога, все же могут ошибиться и выполнить сортировку O (n ^ 2), поэтому, чтобы быть в безопасности, я бы всегда ограничивал количество файлов в каталог не более 500.

Это действительно зависит от используемой файловой системы, а также от некоторых флагов.

Например, ext3 может иметь много тысяч файлов; но после пары тысяч это было очень медленно. В основном при выводе каталога, а также при открытии одного файла. Несколько лет назад он получил опцию «htree», которая значительно сократила время, необходимое для получения inode с заданным именем файла.

Лично я использую подкаталоги, чтобы большинство уровней не превышало тысячи предметов. В вашем случае я бы создал 256 каталогов с двумя последними шестнадцатеричными цифрами идентификатора. Используйте последние, а не первые цифры, чтобы вы сбалансировали нагрузку.

У ext3 действительно есть ограничения на размер каталога, и они зависят от размера блока файловой системы. Существует не «максимальное количество» файлов для каждого каталога, а «максимальное количество блоков, используемых для хранения записей в файлах». В частности, размер самого каталога не может превышать b-дерево высоты 3, и разветвление дерева зависит от размера блока. Смотрите эту ссылку для некоторых деталей.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

Это меня недавно укусило в файловой системе, отформатированной с блоками 2К, которая необъяснимо получала сообщения ядра, заполненные каталогом, warning: ext3_dx_add_entry: Directory index full!когда я копировал из другой файловой системы ext3. В моем случае каталог с просто 480 000 файлов не удалось скопировать в место назначения.

Вопрос сводится к тому, что вы собираетесь делать с файлами.

Под Windows любой каталог с более чем 2k файлами имеет тенденцию открываться медленно для меня в Проводнике. Если все они являются файлами изображений, более 1 КБ имеют тенденцию открываться очень медленно в режиме просмотра миниатюр.

Одно время системный лимит составлял 32 767. Сейчас он выше, но даже это слишком много файлов для обработки в большинстве случаев.

То, что большинство ответов выше не показывают, - это то, что не существует ответа «Один размер подходит всем» на исходный вопрос.

В сегодняшних условиях у нас большой конгломерат различного оборудования и программного обеспечения - некоторые 32-битные, некоторые 64-битные, некоторые современные, некоторые проверенные и надежные - надежные и никогда не меняющиеся. К этому добавляются различные старые и новые аппаратные средства, старые и новые операционные системы, разные поставщики (Windows, Unixes, Apple и т. Д.), А также множество утилит и серверов. Поскольку аппаратное обеспечение улучшилось, а программное обеспечение преобразовано в 64-битную совместимость, неизбежно произошла значительная задержка в том, чтобы все части этого очень большого и сложного мира хорошо играли с быстрыми темпами изменений.

ИМХО нет одного способа решить проблему. Решение состоит в том, чтобы исследовать возможности, а затем методом проб и ошибок найти то, что лучше всего подходит для ваших конкретных потребностей. Каждый пользователь должен определить, что работает для его системы, а не использовать подход к формам cookie.

Например, у меня есть медиа-сервер с несколькими очень большими файлами. В результате получается всего около 400 файлов, заполняющих диск объемом 3 ТБ. Используется только 1% инодов, но используется 95% от общего пространства. Кто-то другой, с большим количеством файлов меньшего размера, может исчерпать иноды, прежде чем они приблизятся к заполнению пространства. (В файловых системах ext4, как правило, 1 индекс используется для каждого файла / каталога.) Хотя теоретически общее количество файлов, которые могут содержаться в каталоге, почти бесконечно, практичность определяет, что общее использование определяет реалистичные единицы, а не только возможности файловой системы.

Я надеюсь, что все различные ответы, приведенные выше, способствовали мысли и решению проблем, а не ставили непреодолимый барьер для прогресса.

Я помню, как запустил программу, которая создавала огромное количество файлов на выходе. Файлы были отсортированы по 30000 за каталог. Я не припоминаю каких-либо проблем с чтением, когда мне приходилось повторно использовать полученный вывод. Он был на 32-битном ноутбуке с Ubuntu Linux, и даже Nautilus отображал содержимое каталога, хотя и через несколько секунд.

Файловая система ext3: Аналогичный код в 64-битной системе хорошо справлялся с 64000 файлами на каталог.

«Зависит от файловой системы»
Некоторые пользователи отметили, что влияние на производительность зависит от используемой файловой системы. Конечно. Файловые системы, такие как EXT3, могут быть очень медленными. Но даже если вы используете EXT4 или XFS вы не можете предотвратить , что листинг папки через lsили findили через внешнее соединение , как FTP будет медленнее медленнее.

Решение
Я предпочитаю так же, как @armandino . Для этого я использую эту маленькую функцию в PHP для преобразования идентификаторов в путь к файлу, который дает 1000 файлов на каталог:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

или вы можете использовать вторую версию, если хотите использовать буквенно-цифровые символы:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

Результаты:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Как вы можете видеть для $int-version, каждая папка содержит до 1000 файлов и до 99 каталогов, содержащих 1000 файлов и 99 каталогов ...

Но не стоит забывать, что у многих каталогов одни и те же проблемы с производительностью!

Наконец, вы должны подумать о том, как уменьшить общее количество файлов. В зависимости от вашей цели вы можете использовать CSS-спрайты для объединения нескольких крошечных изображений, таких как аватары, значки, смайлики и т. Д., Или, если вы используете много небольших не мультимедийных файлов, рассмотрите возможность их объединения, например, в формате JSON. В моем случае у меня были тысячи мини-кешей, и в конце концов я решил объединить их в пакеты по 10 штук.

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

Я столкнулся с аналогичной проблемой. Я пытался получить доступ к каталогу с более чем 10000 файлов в нем. Создание списка файлов и выполнение команд любого типа для любого из файлов заняло слишком много времени.

Я придумал небольшой скрипт php, чтобы сделать это для себя, и попытался найти способ, как предотвратить это в браузере.

Ниже приведен скрипт php, который я написал для решения проблемы.

Перечисление файлов в каталоге со слишком большим количеством файлов для FTP

Как это помогает кому-то

Не ответ, а только некоторые предложения.

Выберите более подходящую FS (файловую систему). Так как с исторической точки зрения все ваши проблемы были достаточно мудрыми, чтобы когда-то быть центральными для ФС, развивающихся в течение десятилетий. Я имею в виду более современные ПС лучше поддерживают ваши проблемы. Сначала составьте таблицу решений для сравнения на основе вашей конечной цели из списка FS .

Я думаю, что пришло время изменить ваши парадигмы. Поэтому я лично предлагаю использовать распределенную систему с учетом ФС , что означает отсутствие каких-либо ограничений в отношении размера, количества файлов и т. Д. В противном случае вы рано или поздно столкнетесь с новыми непредвиденными проблемами.

Я не уверен, что работать, но если вы не упомянули некоторые эксперименты, попробуйте AUFS поверх вашей текущей файловой системы. Я предполагаю, что у этого есть средства для имитации нескольких папок как одной виртуальной папки.

Для преодоления аппаратных ограничений вы можете использовать RAID-0.

Не существует единственного числа, которое является «слишком большим», если оно не выходит за пределы операционной системы. Однако чем больше файлов в каталоге, независимо от ОС, тем больше времени требуется для доступа к любому отдельному файлу, а на большинстве ОС производительность нелинейная, поэтому для поиска одного файла из 10000 требуется более чем в 10 раз больше времени. затем найти файл в 1000.

Вторичные проблемы, связанные с наличием большого количества файлов в каталоге, включают в себя ошибки расширения подстановочных знаков. Чтобы снизить риски, вы можете подумать о том, чтобы упорядочить каталоги по дате загрузки или другим полезным метаданным.