Сколько файлов я могу поместить в каталог?


561

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

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

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

Ответы:


736

FAT32 :

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

NTFS :

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

ext2 :

  • Максимальное количество файлов: 10 18
  • Максимальное количество файлов в каталоге: ~ 1,3 × 10 20 (проблемы с производительностью после 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 13 , numberOfBlocks)
  • Максимальный размер файла: такой же, как у ext2
  • Максимальный размер тома: такой же, как у ext2

ext4 :

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

24
Я предполагаю, что это максимальное количество файлов для всего раздела, а не для каталога. Таким образом, эта информация не слишком полезна в отношении проблемы, потому что там будет одинаковое количество файлов независимо от метода (если не считать каталоги как файлы).
Страгер

19
Поскольку мы находимся в 2012 году, думаю, пришло время прояснить, что у ext4 нет ограничений по количеству подкаталогов. Также максимальный размер файла вырос до 16 ТБ. Кроме того, общий размер файловой системы может составлять до 1 ЭБ = 1 048 576 ТБ.
devsnd

7
Очевидно, ext3 также имеет ограничение в 60000 файлов (или каталогов или ссылок) на каталог. Я выяснил трудный путь по этому поводу.
ст.

8
Старый ответ, я знаю ... но когда вы пишете EXT4 - Максимальное количество файлов: 2³² - 1 (4,294,967,295) и Максимальное количество файлов в каталоге: неограниченно, вы действительно смутили меня, потому что 2³² - 1! = «Неограниченно». Я думаю, мне сейчас нужен кофе. ;) Тем не менее +1
e-sushi

12
жесткие ограничения файловой системы не отвечают на вопрос « Имеет ли значение, сколько файлов я храню в одном каталоге? »
Etki

191

У меня было более 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()так что вы можете указать буфер размер при чтении записей каталога с диска.


6
Интересно читать! Могу я спросить, в какой ситуации у вас было 8 миллионов файлов в одном каталоге? ха - ха
Aᴄʜᴇʀᴏɴғᴀɪʟ

У меня было то же самое. Я перенес столбец блобов таблицы, каждый столбец блобов я экспортировал в виде файла. Это около 8 миллионов файлов :)
Спайк

66

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

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

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


6
Это единственный полезный ответ. Мы сделали похожий опыт. Наш лимит составляет 1000 файлов, чтобы уменьшить проблемы с резервными копиями (слишком большое количество каталогов также замедляется).
mgutt

1
Также может быть полезно смонтировать диск с noatime: howtoforge.com/… и прочитать его тоже: serverfault.com/questions/354017/…
mgutt

2
Какую файловую систему вы используете, где она сильно тормозит? Например, XFS должна легко обрабатывать 100 000 файлов в каталоге без заметного замедления.
Итан

1
Вопреки мнению большинства других, я хочу подтвердить этот ответ. У нас есть сотни тысяч изображений в нашей социальной сети. Чтобы повысить производительность, мы были вынуждены иметь 100 (или 1000 для некоторых файлов) подкаталогов и распределять файлы по ним (ext3 на linux + Apache для нас).
Wmac

57

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

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

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


4
Gnome и KDE загружают большие каталоги со скоростью улитки, Windows будет кэшировать каталог, поэтому это разумно. Я люблю Linux, но kde и gnome плохо написаны.
Ладья

1
И ext4, по-видимому, имеет эквивалент dir_index по умолчанию.
Профессор Фалькен нарушил договор

22
В ext3 существует ограничение около 32K подкаталогов в одном каталоге, но OP говорит о файлах изображений. Нет ограничений (практично?) Для файлов в файловой системе ext3 с включенным Dir Index.
Питер Н Льюис

1
Этот ответ устарел, в настоящее время по умолчанию используется ext4 .
Борис

1
«Не существует (практического?) Ограничения на файлы в файловой системе ext3 с включенным Dir Index» - я просто исчерпал файловое пространство в каталоге файловой системы ext4 4 ТБ, с dir_indexвключенным. У меня было около 17 миллионов файлов в каталоге. Ответ состоял в том, чтобы включить large_dirtune2fs.
Lunixbochs

49

Имейте в виду, что в 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

33
@Steve, используйте find (1) и / или xargs (1) для этих случаев. По той же причине рекомендуется использовать такие инструменты в сценариях вместо расширения командной строки.
Дэйв С

3
@ Стив, вы видите, как снижается производительность, когда увеличивается количество файлов в папке? Или нет никакого отношения?
Pacerier

6
Это хорошая точка зрения, но, как ни странно, причина неверна. Список_аргументы слишком долго это ограничение не оболочек, но система execреализации. Оболочка, как правило, прекрасно расширяет подстановочный знак - вызов execс таким количеством аргументов возвращает ошибку.
jw013

Вчера вечером у меня была такая же ошибка (Fedora 15) с "rm" (somefiles *) с ~ 400 000 файлов в каталоге. Я был в состоянии обрезать старые файлы с помощью «find» до точки, где я мог «rm» с подстановочным знаком.
PJ Brunet

10.000.000 файлов в каталог на etx4 работает нормально. При доступе не сильно страдает производительность. Но довольно медленно с подстановочными знаками. Будьте осторожны при использовании программ оболочки, которые любят сортировать имена файлов! :)
Саймон Ригет

25

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

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

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

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


1
Это довольно хорошее решение. Каждый уровень вашего каталога, вплоть до файла, будет содержать не более 100 записей, если придерживаться разбивки из 2 цифр, а в самом нижнем каталоге будет только 1 файл.
RobKohr

Реализация PHP: stackoverflow.com/a/29707920/318765
mgutt

21

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

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


что за файлы? текст или изображения? Я нахожусь на ext4 и должен импортировать 80000 изображений в один каталог под WordPress и хотел бы знать, будет ли это хорошо
Ивон

2
@YvonHuynh: тип файла совершенно не имеет значения. Накладные расходы в каталоге листинга / отслеживания файла одинаковы независимо.
TJ Crowder

14

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

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


9

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

эталонный тест

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


Ссылка на решение приветствуется, но, пожалуйста, убедитесь, что ваш ответ полезен без нее: добавьте контекст вокруг ссылки, чтобы ваши коллеги-пользователи имели представление о том, что это такое и почему, а затем процитируйте наиболее релевантную часть страницы, которую вы ' Повторная ссылка на случай, если целевая страница недоступна. Ответы, которые немного больше, чем ссылка, могут быть удалены.
Самуэль Лью

1
Интересно. Мы обнаружили, что даже после 10 000 файлов производительность очень быстро снижается до такой степени, что становится непригодной для использования. Мы решили разбить файлы на подкаталоги по 100 на каждом уровне для достижения оптимальной производительности. Я полагаю, что мораль этой истории - всегда сравнивать ее для себя в своих системах с вашими требованиями.
Джошуа Пинтер

7

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

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


6
Я рекламирую против разделения по дате, потому что массовый импорт может кластеризовать файлы на определенную дату.
максимум

Хороший вопрос. Вы должны обязательно рассмотреть ваши варианты использования, прежде чем выбрать схему разделения. Мне довелось импортировать фотографии в течение многих дней в относительно широком распространении, И когда я хочу манипулировать фотографиями вне даты F-Spot, это самый простой способ найти их, поэтому для меня это двойная победа.
Спарр

7

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

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


7

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

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

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


6
Если имена файлов были абсолютно случайными, неважно, какие цифры использовались.
Страгер

Действительно, эти имена файлов генерируются случайным образом.
Кип

2
Или используйте первые N байтов дайджеста SHA-1 имени файла.
Гави

6

У 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 файлов не удалось скопировать в место назначения.


5

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

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

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


5

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

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

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

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

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


4

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

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


4

«Зависит от файловой системы»
Некоторые пользователи отметили, что влияние на производительность зависит от используемой файловой системы. Конечно. Файловые системы, такие как 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 штук.


3

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


3

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

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

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

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

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


1

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

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

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

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

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


1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.