Сколько файлов я могу поместить в каталог?
Имеет ли значение, сколько файлов я храню в одном каталоге? Если так, сколько файлов в каталоге слишком много, и каково влияние наличия слишком большого количества файлов? (Это на сервере Linux.)
Фон: у меня есть веб-сайт фотоальбома, и каждое загруженное изображение переименовывается в 8-шестнадцатеричный идентификатор (скажем, a58f375c.jpg). Это делается для того, чтобы избежать конфликтов имен файлов (например, если загружено много файлов "IMG0001.JPG"). Исходное имя файла и любые полезные метаданные хранятся в базе данных. Сейчас у меня где-то около 1500 файлов в каталоге изображений. Это приводит к тому, что перечисление файлов в каталоге (через FTP или SSH-клиент) занимает несколько секунд. Но я не вижу, что это имеет какое-либо влияние, кроме этого. В частности, похоже, что скорость передачи файла изображения пользователю не влияет.
Я думал об уменьшении количества изображений, создав 16 подкаталогов: 0-9 и af. Затем я переместил бы изображения в подкаталоги, основываясь на том, какой была первая шестнадцатеричная цифра имени файла. Но я не уверен, что для этого есть какая-либо причина, кроме случайного просмотра каталога через FTP/SSH.
23 ответа
FAT32:
- Максимальное количество файлов: 268 173 300
- Максимальное количество файлов в каталоге: 216 - 1 (65 535)
- Максимальный размер файла: 2 ГиБ - 1 без LFS, 4 ГиБ - 1 с
NTFS:
- Максимальное количество файлов: 232 - 1 (4 294 967 295)
- Максимальный размер файла
- Реализация: 244 - 26 байтов (16 TiB - 64 KiB)
- Теоретический: 264 - 26 байтов (16 EiB - 64 КиБ)
- Максимальный размер тома
- Реализация: 232 - 1 кластер (256 ТиБ - 64 КиБ)
- Теоретически: 264 - 1 кластера (1 Yi - 64 КиБ)
ext2:
- Максимальное количество файлов: 1018
- Максимальное количество файлов в каталоге: ~1,3 × 1020 (проблемы с производительностью после 10000)
- Максимальный размер файла
- 16 ГиБ (размер блока 1 КиБ)
- 256 ГиБ (размер блока 2 КиБ)
- 2 TiB (размер блока 4 КиБ)
- 2 TiB (размер блока 8 КиБ)
- Максимальный размер тома
- 4 TiB (размер блока 1 КиБ)
- 8 ТиБ (размер блока 2 КиБ)
- 16 ТиБ (размер блока 4 КиБ)
- 32 TiB (размер блока 8 КиБ)
ext3:
- Максимальное количество файлов: min (volumeSize / 213, numberOfBlocks)
- Максимальный размер файла: такой же, как у ext2
- Максимальный размер тома: такой же, как у ext2
ext4:
- Максимальное количество файлов: 232 - 1 (4 294 967 295)
- Максимальное количество файлов в каталоге: не ограничено
- Максимальный размер файла: 244 - 1 байт (16 ТиБ - 1)
- Максимальный размер тома: 248 - 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-ls/
Ключ забрать это: использовать 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 файловая система с 1000 000 файлов в ней, а затем случайным образом получить доступ к этим файлам через веб-сервер. Я не заметил никакой премии за доступ к тем, у кого, скажем, только 10 файлов там.
Это радикально отличается от моего опыта в ntfs несколько лет назад.
У меня была такая же проблема. Попытка сохранить миллионы файлов на сервере Ubuntu в ext4. Закончились мои собственные тесты. Выяснилось, что плоский каталог работает намного лучше, но при этом гораздо проще в использовании:
ht tps://stackru.com/images/94194e4201c99749614aa3ac7bb57dce a2680a72.png
Написал статью.
Самая большая проблема, с которой я столкнулся, связана с 32-битной системой. Как только вы передадите определенное число, такие инструменты, как 'ls', перестанут работать.
Попытка что-либо сделать с этим каталогом, когда вы преодолеете этот барьер, становится огромной проблемой.
Это действительно зависит от используемой файловой системы, а также от некоторых флагов.
Например, ext3 может иметь много тысяч файлов; но после пары тысяч это было очень медленно. Главным образом при перечислении каталога, но также и при открытии одного файла. Несколько лет назад он получил опцию "htree", которая значительно сократила время, необходимое для получения inode с заданным именем файла.
Лично я использую подкаталоги, чтобы большинство уровней не превышало тысячи предметов. В вашем случае я бы создал 256 каталогов с двумя последними шестнадцатеричными цифрами идентификатора. Используйте последние, а не первые цифры, чтобы вы сбалансировали нагрузку.
Если время, необходимое для реализации схемы разбиения каталогов, минимально, я за это. В первый раз, когда вам придется отлаживать проблему, которая включает в себя манипулирование каталогом из 10000 файлов через консоль, вы поймете.
Например, F-Spot хранит файлы фотографий в формате YYYY\MM\DD\filename.ext, что означает, что самый большой каталог, с которым мне приходилось иметь дело при манипулировании моей коллекцией ~20000 фотографий, составляет около 800 файлов. Это также делает файлы более легкими для просмотра из стороннего приложения. Никогда не думайте, что ваше программное обеспечение - единственное, что будет иметь доступ к файлам вашего программного обеспечения.
Я предпочитаю так же, как @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-версия каждой папки содержит до 1000 файлов и до 99 каталогов, содержащих 1000 файлов и 99 каталогов...
Но не забывайте, что многие каталоги могут ускорить процесс резервного копирования. Не стесняйтесь тестировать от 1000 до 10000 файлов в каталоге, но не добавляйте намного больше, так как у вас будет очень много времени доступа, если вы хотите читать файл каталога по файлу (FTP-клиенты, функции чтения файлов и т. Д.).
Наконец, вы должны подумать о том, как уменьшить общее количество файлов. В зависимости от вашей цели вы можете использовать CSS-спрайты для объединения нескольких крошечных изображений, таких как аватары, значки, смайлики и т. Д., Или, если вы используете много небольших файлов, не относящихся к мультимедиа, рассмотрите возможность их объединения, например, в формате JSON. В моем случае у меня были тысячи мини-кешей, и в конце концов я решил объединить их в пакеты по 10 штук.
Это абсолютно зависит от файловой системы. Многие современные файловые системы используют приличные структуры данных для хранения содержимого каталогов, но старые файловые системы часто просто добавляли записи в список, поэтому получение файла было операцией O(n).
Даже если файловая система делает все правильно, программы, перечисляющие содержимое каталогов, все равно могут полностью испортиться и выполнить сортировку O(n^2), поэтому, чтобы быть в безопасности, я бы всегда ограничивал количество файлов в каталог не более 500.
У ext3 действительно есть ограничения на размер каталога, и они зависят от размера блока файловой системы. Существует не "максимальное количество" файлов для каждого каталога, а "максимальное количество блоков, используемых для хранения записей в файлах". В частности, размер самого каталога не может превышать b-дерево высоты 3, и разветвление дерева зависит от размера блока. Смотрите эту ссылку для некоторых деталей.
https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html
Я был недавно укушен этим в файловой системе, отформатированной с блоками 2K, которая необъяснимым образом получала сообщения ядра, заполненные каталогами. warning: ext3_dx_add_entry: Directory index full! когда я копировал из другой файловой системы ext3. В моем случае каталог с просто 480000 файлов не удалось скопировать в место назначения.
То, что большинство ответов выше не показывают, - это то, что не существует ответа "один размер подходит всем" на исходный вопрос.
В сегодняшних условиях у нас большой конгломерат различного оборудования и программного обеспечения - некоторые 32-битные, некоторые 64-битные, некоторые современные, некоторые проверенные и надежные - надежные и никогда не меняющиеся. К этому добавляются различные старые и новые аппаратные средства, старые и новые операционные системы, разные поставщики (Windows, Unixes, Apple и т. Д.), А также множество утилит и серверов. Поскольку аппаратное обеспечение улучшилось, а программное обеспечение преобразовано в 64-битную совместимость, неизбежно произошла значительная задержка, чтобы все части этого очень большого и сложного мира хорошо играли с быстрым темпом изменений.
ИМХО нет одного способа решить проблему. Решение состоит в том, чтобы исследовать возможности, а затем методом проб и ошибок найти то, что лучше всего подходит для ваших конкретных потребностей. Каждый пользователь должен определить, что работает для его системы, а не использовать подход к формам печенья.
Например, у меня есть медиа-сервер с несколькими очень большими файлами. В результате получается всего около 400 файлов, заполняющих диск объемом 3 ТБ. Используется только 1% инодов, но используется 95% общего пространства. Кто-то другой, с большим количеством файлов меньшего размера, может исчерпать inode, прежде чем они приблизятся к заполнению пространства. (В файловых системах ext4, как правило, 1 индекс используется для каждого файла / каталога.) Хотя теоретически общее количество файлов, которые могут содержаться в каталоге, практически бесконечно, практичность определяет, что общее использование определяет реалистичные единицы, а не только возможности файловой системы.
Я надеюсь, что все различные ответы, приведенные выше, способствовали мысли и решению проблем, а не ставили непреодолимый барьер для прогресса.
Вопрос сводится к тому, что вы собираетесь делать с файлами.
Под Windows любой каталог с более чем 2k файлами имеет тенденцию открываться медленно для меня в Проводнике. Если все они являются файлами изображений, более 1 КБ имеют тенденцию открываться очень медленно в режиме просмотра миниатюр.
Одно время системный лимит составлял 32 767 человек. Сейчас он выше, но даже это слишком много файлов для обработки за один раз в большинстве случаев.
Я помню, как запустил программу, которая создавала огромное количество файлов на выходе. Файлы были отсортированы по 30000 за каталог. Я не припоминаю каких-либо проблем с чтением, когда мне приходилось повторно использовать полученный вывод. Он был на 32-битном ноутбуке с Ubuntu Linux, и даже Nautilus отображал содержимое каталога, хотя и через несколько секунд.
Файловая система ext3: аналогичный код в 64-битной системе хорошо справлялся с 64000 файлами на каталог.
Я столкнулся с аналогичной проблемой. Я пытался получить доступ к каталогу с более чем 10000 файлов в нем. Создание списка файлов и выполнение команд любого типа для любого из файлов заняло слишком много времени.
Я придумал небольшой скрипт php, чтобы сделать это для себя, и попытался найти способ, как предотвратить это в браузере.
Ниже приведен скрипт php, который я написал для решения проблемы.
Перечисление файлов в каталоге со слишком большим количеством файлов для FTP
Как это помогает кому-то
Я уважаю, что это не полностью отвечает на ваш вопрос относительно того, сколько их слишком много, но идея для решения долгосрочной проблемы заключается в том, что помимо хранения метаданных исходного файла также хранится папка на диске, в которой он хранится - нормализуйте этот кусок метаданных. Как только папка выходит за пределы предела, который вас устраивает по производительности, эстетике или по любой другой причине, вы просто создаете вторую папку и начинаете сбрасывать туда файлы...
Не ответ, а только некоторые предложения.
Выберите более подходящую ФС (файловую систему). Так как с исторической точки зрения все ваши проблемы были достаточно мудрыми, чтобы когда-то быть центральными для ФС, развивающихся в течение десятилетий. Я имею в виду более современные ПС лучше поддерживают ваши проблемы. Сначала составьте таблицу решений для сравнения на основе вашей конечной цели из списка FS.
Я думаю, что пришло время изменить ваши парадигмы. Поэтому я лично предлагаю использовать распределенную систему с поддержкой FS, что означает отсутствие каких-либо ограничений в отношении размера, количества файлов и т. Д. В противном случае вы рано или поздно столкнетесь с новыми непредвиденными проблемами.
Я не уверен, что работать, но если вы не упомянули некоторые эксперименты, попробуйте AUFS поверх вашей текущей файловой системы. Я предполагаю, что у этого есть средства, чтобы подражать многократным папкам как одна виртуальная папка.
Для преодоления аппаратных ограничений вы можете использовать RAID-0.
Не существует единственного числа, которое является "слишком большим", если оно не выходит за пределы операционной системы. Однако чем больше файлов в каталоге, независимо от ОС, тем больше времени требуется для доступа к любому отдельному файлу, а на большинстве ОС производительность нелинейная, поэтому для поиска одного файла из 10000 требуется более чем в 10 раз больше времени. затем найти файл в 1000.
Вторичные проблемы, связанные с наличием большого количества файлов в каталоге, включают сбои раскрытия подстановочных знаков. Чтобы снизить риски, вы можете подумать о том, чтобы упорядочить каталоги по дате загрузки или другим полезным метаданным.
≈ 135000 ФАЙЛОВ
НТФС | СЕРВЕР WINDOWS 2012 | 64-БИТ | Жесткий диск емкостью 4 ТБ | ВБС
Проблема . Катастрофические проблемы с оборудованием возникают, когда [одна] конкретная папка содержит примерно 135000 файлов.
- «Катастрофический» = перегрев ЦП, выключается компьютер, требуется замена оборудования
- «Определенная папка» = имеет файл VBS, который перемещает файлы во вложенные папки.
- Доступ = к папке автоматически обращаются/выполняются несколько клиентских компьютеров
По сути, у меня есть собственный сценарий, который находится на файловом сервере. Когда что-то пойдет не так с автоматизированным процессом (т. е. утечка файлов + дамба), тогда конкретная папка будет заполнена [неперемещенными файлами]. Катастрофа принимает форму, когда клиентские компьютеры продолжают выполнять сценарий. В итоге файловый сервер читает более 135000 файлов; и делать это сотни раз каждый день. Эта рабочая перегрузка приводит к перегреву моего процессора (92 ° C и т. Д.); что в конечном итоге приводит к сбою моей машины.
Решение . Убедитесь, что ваши сценарии организации файлов никогда не будут иметь дело с папкой, содержащей более 135000 файлов.
безупречный,
безупречный,
абсолютно безупречный:
function ff () {
d=$1; f=$2;
p=$( echo $f |sed "s/$d.*//; s,\(.\),&/,g; s,/$,," );
echo $p/$f ;
}
ff _D_ 09748abcGHJ_D_my_tagged_doc.json
0/9/7/4/8/a/b/c/G/H/J/09748abcGHJ_D_my_tagged_doc.json
ff - gadsf12-my_car.json
g/a/d/s/f/1/2/gadsf12-my_car.json
а также это
ff _D_ 0123456_D_my_tagged_doc.json
0/1/2/3/4/5/6/0123456_D_my_tagged_doc.json
ff .._D_ 0123456_D_my_tagged_doc.json
0/1/2/3/4/0123456_D_my_tagged_doc.json
Наслаждайтесь !