Максимальное количество файлов в папке Linux
Обновлено: 21.11.2024
Я подумал об уменьшении количества изображений, создав 16 подкаталогов: 0-9 и a-f. Затем я перемещал изображения в подкаталоги в зависимости от того, какой была первая шестнадцатеричная цифра имени файла. Но я не уверен, что для этого есть какая-то причина, кроме случайного просмотра каталога через FTP/SSH.
22 ответа 22
- Максимальное количество файлов: 268 173 300
- Максимальное количество файлов в каталоге: 2 16–1 (65 535)
- Максимальный размер файла: 2 ГиБ – 1 без LFS, 4 ГиБ – 1 с.
- Максимальное количество файлов: 2 32–1 (4 294 967 295)
- Максимальный размер файла
- Реализация: 2 44–2 6 байт (16 ТиБ – 64 КиБ)
- Теоретически: 2 64 – 2 6 байт (16 EiB – 64 КиБ)
- Реализация: 2 32–1 кластера (256 ТиБ – 64 КиБ)
- Теоретически: 2 64 – 1 кластера (1 YiB – 64 КиБ)
- Максимальное количество файлов: 10 18
- Максимальное количество файлов в каталоге: ~1,3 × 10 20 (проблемы с производительностью более 10 000)
- Максимальный размер файла
- 16 ГиБ (размер блока 1 КиБ)
- 256 ГиБ (размер блока 2 КиБ)
- 2 ТиБ (размер блока 4 КиБ)
- 2 ТиБ (размер блока 8 КиБ)
- 4 ТиБ (размер блока 1 КиБ)
- 8 ТиБ (размер блока 2 КиБ)
- 16 ТиБ (размер блока 4 КиБ)
- 32 ТиБ (размер блока 8 КиБ)
- Максимальное количество файлов: min(volumeSize / 2 13 , numberOfBlocks)
- Максимальный размер файла: такой же, как у ext2
- Максимальный размер тома: такой же, как у ext2
- Максимальное количество файлов: 2 32–1 (4 294 967 295)
- Максимальное количество файлов в каталоге: неограниченно
- Максимальный размер файла: 2 44–1 байт (16 ТиБ – 1)
- Максимальный размер тома: 2 48–1 байт (256 ТиБ – 1)
Я предполагаю, что это максимальное количество файлов для всего раздела, а не для каталога. Таким образом, эта информация не слишком полезна для решения проблемы, потому что будет одинаковое количество файлов независимо от метода (если только вы не считаете каталоги файлами).
Поскольку мы находимся в 2012 году, я думаю, пришло время прояснить, что ext4 не имеет ограничений на количество подкаталогов. Также максимальный размер файла вырос до 16 ТБ. Кроме того, общий размер файловой системы может составлять до 1 ЭБ = 1 048 576 ТБ.
Очевидно, что ext3 также имеет ограничение в 60 000 файлов (или каталогов, или ссылок) в каждом каталоге. Я узнал об этом на собственном горьком опыте.
Я знаю, старый ответ… но когда вы пишете EXT4 — Максимальное количество файлов: 2³² — 1 (4 294 967 295) и Максимальное количество файлов в каталоге: неограниченно вы меня действительно смутило, потому что 2³² - 1 != «неограниченно». Думаю, мне сейчас нужен кофе. ;) Тем не менее +1
жесткие ограничения файловой системы не отвечают на вопрос "Имеет ли значение, сколько файлов я храню в одном каталоге?"
У меня было более 8 миллионов файлов в одном каталоге ext3. libc readdir(), который используется find, ls и большинством других методов, обсуждаемых в этой теме, для отображения больших каталогов.
У меня так же было. Я перенес столбец больших двоичных объектов таблицы, каждый столбец больших двоичных объектов я экспортировал в виде файла. Это около 8 миллионов файлов :)
Время от времени может помочь использование ls -U (перечислите записи в порядке каталога) — вероятно, он записывает записи по мере их чтения (не нужно ждать, пока сначала загрузится весь каталог).
У меня есть каталог с 88 914 файлами. Как и вы, это используется для хранения эскизов и на сервере Linux.
Я дал этот ответ, так как большинство людей только что написали, как будут выполняться функции поиска в каталоге, которые вы не будете использовать в папке большого пальца - просто статически отображая файлы, но их интересует производительность того, как файлы могут на самом деле использоваться.
Это единственный полезный ответ. У нас был подобный опыт. Наше ограничение – 1 000 файлов, чтобы уменьшить проблемы с резервным копированием (к тому же слишком большое количество каталогов замедляет работу).
Какую файловую систему вы используете, когда она так сильно тормозит? Например, XFS должна легко обрабатывать 100 000 файлов в каталоге без каких-либо заметных замедлений.
Вопреки мнению большинства других, я хочу подтвердить этот ответ. У нас есть сотни тысяч изображений на нашем веб-сайте в социальной сети. Для повышения производительности мы были вынуждены иметь 100 (или 1000 для некоторых файлов) подкаталогов и размещать в них файлы (для нас ext3 на linux + Apache).
Это немного зависит от конкретной файловой системы, используемой на сервере Linux. В настоящее время по умолчанию используется ext3 с dir_index, что делает поиск в больших каталогах очень быстрым.
Поэтому скорость не должна быть проблемой, кроме той, которую вы уже отметили, а именно то, что листинги занимают больше времени.
Существует ограничение на общее количество файлов в одном каталоге. Кажется, я точно помню, что он работал до 32000 файлов.
Gnome и KDE загружают большие каталоги со скоростью улитки, Windows будет кэшировать каталог, поэтому это разумно. Я люблю Linux, но kde и gnome плохо написаны.
Существует ограничение около 32 000 подкаталогов в одном каталоге в ext3, но ОП говорит о файлах изображений. Нет (практических?) ограничений на файлы в файловой системе ext3 с включенным индексом Dir.
"Нет (практических?) ограничений на количество файлов в файловой системе ext3 с включенным Dir Index" - мне просто не хватило места в каталоге в файловой системе ext4 объемом 4 ТБ с включенным dir_index. У меня было около 17 миллионов файлов в каталоге. Ответ заключался в том, чтобы включить large_dir с помощью tune2fs.
Имейте в виду, что в Linux, если у вас есть каталог со слишком большим количеством файлов, оболочка может не иметь возможности раскрывать подстановочные знаки. У меня проблема с фотоальбомом, размещенным в Linux. Он хранит все измененные изображения в одном каталоге. Хотя файловая система может обрабатывать множество файлов, оболочка не может. Пример:
@Steve, в таких случаях используйте find(1) и/или xargs(1). По той же причине рекомендуется использовать такие инструменты в сценариях вместо расширения командной строки.
@Steve, вы заметили, что производительность падает, когда количество файлов в папке увеличивается? Или отношения нет?
Это хорошее замечание, но если придираться, указанная причина неверна. Слишком длинный список аргументов является ограничением не оболочки, а системной реализации exec. Оболочка, как правило, может прекрасно расширить подстановочный знак — это вызов exec с таким количеством аргументов, который возвращает ошибку.
Прошлой ночью у меня была такая же ошибка (Fedora 15) с "rm" (somefiles*) с примерно 400 000 файлов в каталоге. Мне удалось обрезать старые файлы с помощью «найти» до такой степени, что я мог использовать «rm» с подстановочным знаком.
10 000 000 файлов в каталог на etx4 работает нормально. Не так много удара по производительности при доступе. Но довольно медленно с подстановочным знаком. Будьте осторожны при использовании программ-оболочек, которым нравится сортировать имена файлов! :)
Сейчас работаю над похожей проблемой. У нас есть иерархическая структура каталогов, и мы используем идентификаторы изображений в качестве имен файлов. Например, изображение с id=1234567 размещено в
используя последние 4 цифры, чтобы определить, куда идет файл.
С несколькими тысячами изображений можно использовать одноуровневую иерархию. Наш системный администратор предложил не более пары тысяч файлов в любом каталоге (ext3) для эффективности / резервного копирования / любых других причин, которые он имел в виду.
Это довольно хорошее решение. Каждый уровень вашего каталога вплоть до файла будет иметь не более 100 записей, если вы будете придерживаться двухзначной разбивки, а в самом нижнем каталоге будет только 1 файл.
Что бы это ни стоило, я просто создал каталог в файловой системе ext4 с 1 000 000 файлов в нем, а затем получил произвольный доступ к этим файлам через веб-сервер. Я не заметил каких-либо преимуществ при доступе к тем, у кого есть (скажем) только 10 файлов.
Это радикально отличается от моего опыта работы с ntfs несколько лет назад.
какие файлы? текст или изображения? я на ext4 и должен импортировать 80000 изображений в один каталог под wordpress и хотел бы знать, все ли будет в порядке
@YvonHuynh: Тип файла совершенно не имеет значения. Накладные расходы в каталоге листинга/отслеживания файла одинаковы независимо.
У меня такая же проблема. Попытка хранить миллионы файлов на сервере Ubuntu в ext4. Закончился запуск собственных тестов. Выяснилось, что плоский каталог работает намного лучше, но при этом проще в использовании:
Ссылка на решение приветствуется, но, пожалуйста, убедитесь, что ваш ответ полезен и без нее: добавьте контекст вокруг ссылки, чтобы ваши коллеги-пользователи имели некоторое представление о том, что это такое и почему оно существует, а затем процитируйте наиболее важную часть решения. страницу, на которую вы ссылаетесь, если целевая страница недоступна. Ответы, которые представляют собой не более чем ссылку, могут быть удалены.
Интересно. Мы обнаружили, что даже после 10 000 файлов производительность очень быстро падала до такой степени, что ее нельзя было использовать. Мы решили разбить файлы на подкаталоги примерно по 100 на каждом уровне для достижения оптимальной производительности. Я полагаю, что мораль этой истории заключается в том, чтобы всегда сравнивать это для себя на своих собственных системах со своими собственными требованиями.
Прочитав статью, я не понял выводов. Вы делаете вывод «использовать плоскую структуру» в первой части. Затем «я не смог запустить тест с большим количеством файлов» (таким образом, здесь нет реального теста?). Наконец, «придерживайтесь здравого смысла и используйте глубокую структуру каталогов».Кроме того, вы можете написать ms вместо s в столбцах слева на ваших графиках.
Самая большая проблема, с которой я столкнулся, связана с 32-разрядной системой. Как только вы передадите определенное число, такие инструменты, как 'ls', перестанут работать.
Попытка сделать что-либо с этим каталогом после преодоления этого барьера становится огромной проблемой.
Это действительно зависит от используемой файловой системы, а также от некоторых флагов.
Например, в ext3 может быть несколько тысяч файлов; но после пары тысяч раньше было очень медленно. В основном при перечислении каталога, но также и при открытии одного файла. Несколько лет назад он получил опцию «htree», которая значительно сократила время, необходимое для получения индексного дескриптора с заданным именем файла.
Лично я использую подкаталоги, чтобы на большинстве уровней было меньше тысячи или около того элементов. В вашем случае я бы создал 256 каталогов с двумя последними шестнадцатеричными цифрами идентификатора. Используйте последние, а не первые цифры, чтобы сбалансировать нагрузку.
Если время, затрачиваемое на реализацию схемы разделения каталога, минимально, я поддерживаю ее. В первый раз, когда вам придется отлаживать проблему, связанную с манипулированием каталогом из 10 000 файлов через консоль, вы поймете.
Например, F-Spot хранит файлы фотографий в формате ГГГГ\ММ\ДД\имя_файла.ext, что означает, что самый большой каталог, с которым мне приходилось иметь дело при ручном управлении моей коллекцией из примерно 20 000 фотографий, составляет около 800 файлов. Это также упрощает просмотр файлов из стороннего приложения. Никогда не думайте, что ваше программное обеспечение — это единственное, что будет иметь доступ к файлам вашего программного обеспечения.
Хорошее замечание. Вы обязательно должны рассмотреть варианты использования, прежде чем выбирать схему разбиения. Мне приходится импортировать фотографии в течение многих дней в относительно большом количестве, И когда я хочу манипулировать фотографиями за пределами F-Spot, дата — это самый простой способ найти их, так что это двойной выигрыш для меня.
Это абсолютно зависит от файловой системы. Многие современные файловые системы используют приличные структуры данных для хранения содержимого каталогов, но старые файловые системы часто просто добавляли записи в список, поэтому извлечение файла занимало операцию O(n).
Даже если файловая система делает это правильно, программы, отображающие содержимое каталогов, все равно могут ошибаться и выполнять сортировку O(n^2), поэтому на всякий случай я всегда ограничиваю число файлов в каталоге до не более 500.
На самом деле ext3 имеет ограничения на размер каталога, и они зависят от размера блока файловой системы. Существует не «максимальное количество» файлов для каждого каталога, а «максимальное количество блоков, используемых для хранения файловых записей» для каждого каталога. В частности, размер самого каталога не может вырасти за пределы b-дерева высотой 3, а разветвление дерева зависит от размера блока. Подробнее см. по этой ссылке.
Недавно я был укушен этим в файловой системе, отформатированной блоками по 2 КБ, которая необъяснимым образом получала предупреждения ядра о заполнении каталога: ext3_dx_add_entry: Индекс каталога заполнен! когда я копировал из другой файловой системы ext3. В моем случае каталог, содержащий всего 480 000 файлов, не удалось скопировать в место назначения.
Вопрос сводится к тому, что вы собираетесь делать с файлами.
Под Windows любой каталог с более чем 2 КБ файлов медленно открывается для меня в проводнике. Если это все файлы изображений, более 1 КБ, как правило, открываются очень медленно в режиме миниатюр.
Однажды установленное системой ограничение составляло 32 767. Сейчас он выше, но даже это слишком много файлов для одновременной обработки в большинстве случаев.
Большинство приведенных выше ответов не показывают, что на исходный вопрос не существует универсального ответа.
В сегодняшних условиях у нас есть большой конгломерат различного оборудования и программного обеспечения: некоторые из них 32-разрядные, некоторые 64-разрядные, некоторые передовые, а некоторые проверенные и надежные - надежные и никогда не меняющиеся. К этому добавляется разнообразие старого и нового оборудования, старых и новых ОС, разных поставщиков (Windows, Unix, Apple и т. д.) и множество сопутствующих утилит и серверов. По мере совершенствования оборудования и перевода программного обеспечения на 64-разрядную совместимость неизбежно возникали значительные задержки с тем, чтобы заставить все части этого очень большого и сложного мира хорошо работать с быстрым темпом изменений.
ИМХО, нет единого способа решить проблему. Решение состоит в том, чтобы исследовать возможности, а затем путем проб и ошибок найти то, что лучше всего подходит для ваших конкретных нужд. Каждый пользователь должен определить, что подходит для его системы, а не использовать шаблонный подход.
Например, у меня есть медиасервер с несколькими очень большими файлами. В результате всего около 400 файлов заполняют диск объемом 3 ТБ. Используется только 1% инодов, но используется 95% всего пространства.У кого-то другого, с большим количеством файлов меньшего размера, могут закончиться индексные дескрипторы, прежде чем они приблизится к заполнению пространства. (На файловых системах ext4, как правило, для каждого файла/каталога используется 1 индексный дескриптор.) Хотя теоретически общее количество файлов, которые могут содержаться в каталоге, почти бесконечно, практичность определяет, что общее использование определяет реалистичные единицы, а не просто возможности файловой системы.
Я надеюсь, что все приведенные выше ответы способствовали размышлениям и решению проблем, а не создавали непреодолимое препятствие на пути к прогрессу.
Перейдите к папке, содержащей файлы, которые вы хотите подсчитать. Выделите один из файлов в этой папке и нажмите сочетание клавиш Ctrl + A, чтобы выделить все файлы и папки в этой папке. В строке состояния Проводника вы увидите, сколько файлов и папок выделено, как показано на рисунке ниже.
Существует ли максимальное количество файлов в папке?
Суммарный размер всех файлов в папке практически не ограничен, хотя могут быть ограничения на количество файлов в папке. Что еще более важно, существуют ограничения на размер отдельных файлов, которые зависят от того, какую файловую систему вы используете на своем жестком диске.
Сколько файлов находится в корневом каталоге?
Неважно, много ли у вас свободного места на жестком диске, в корневом каталоге может быть не более 512 файлов.
Сколько папок можно создать в папке в Linux?
Количество возможных каталогов/подпапок ограничено количеством индексных дескрипторов файловой системы. Например, в ext3 это обычно V/2, где V — размер тома в байтах. Таким образом, количество вложенных уровней для папок не ограничено.
Насколько большой может быть папка?
Вы можете поместить 4 294 967 295 файлов в одну папку, если диск отформатирован в NTFS (было бы необычно, если бы это было не так), если вы не превышаете 256 терабайт (размер одного файла и пространство) или все дисковое пространство, которое было доступно в зависимости от того, что меньше.
Существует ли ограничение на количество файлов, которые вы можете заархивировать?
Ограничения. Максимальный размер архивного файла и отдельных файлов внутри него составляет 4 294 967 295 байт (2 32 -1 байт или 4 ГБ минус 1 байт) для стандартного ZIP. Для ZIP64 максимальный размер составляет 18 446 744 073 709 551 615 байт (2 64 – 1 байт, или 16 ЭБ минус 1 байт).
Что такое ограничение файловой системы?
Этот предельный размер обычно составляет от 40 гигабайт (ГБ) до 90 ГБ для очень фрагментированного файла. … Сильно фрагментированный файл в томе файловой системы NTFS не может превышать определенный размер, вызванный ограничением реализации в структурах, которые используются для описания распределения.
Что такое корень каталога?
Корневая папка, также называемая корневым каталогом или иногда просто корнем любого раздела или папки, является «самым высоким» каталогом в иерархии. Вы также можете думать об этом в целом как о начале или начале определенной структуры папок.
На что указывает запись в каталоге?
На что указывает запись .. в каталоге? В unix или unix-подобных системах запись «..» указывает на родительский каталог указанного каталога. Это обеспечивает древовидную структуру с использованием двух ссылок: одна указывает на ветки ниже текущего каталога (с использованием имени подкаталога) и ссылка вверх по дереву.
У меня есть каталог, содержащий более 400 000 файлов. Потенциально каталог может легко содержать около 30 000 000 файлов.
Хорошая ли это идея, или мне лучше разбить ее на более мелкие каталоги, как здесь:
Какого размера я должен сделать меньшие каталоги? Будет ли 100 000 файлов в каждом каталоге хорошей идеей?
2 ответа 2
Я попробую.
С точки зрения файловой системы:
- Максимальное количество файлов: 268 173 300
- Максимальное количество файлов в каталоге: 2 16–1 (65 535)
- Максимальный размер файла: 2 ГиБ – 1 без LFS, 4 ГиБ – 1 с.
- Максимальное количество файлов: 2 32–1 (4 294 967 295)
- Максимальный размер файла
- Реализация: 2 44–2 6 байт (16 ТиБ – 64 КиБ)
- Теоретически: 2 64 – 2 6 байт (16 EiB – 64 КиБ)
- Реализация: 2 32–1 кластера (256 ТиБ – 64 КиБ)
- Теоретическое значение: 2 64 – 1 кластер.
- Максимальное количество файлов: 10 18
- Максимальное количество файлов в каталоге: ~1,3 × 10 20 (проблемы с производительностью более 10 000)
- Максимальный размер файла
- 16 ГиБ (размер блока 1 КиБ)
- 256 ГиБ (размер блока 2 КиБ)
- 2 ТиБ (размер блока 4 КиБ)
- 2 ТиБ (размер блока 8 КиБ)
- 4 ТиБ (размер блока 1 КиБ)
- 8 ТиБ (размер блока 2 КиБ)
- 16 ТиБ (размер блока 4 КиБ)
- 32 ТиБ (размер блока 8 КиБ)
- Максимальное количество файлов: min(volumeSize / 2 13 , numberOfBlocks)
- Максимальный размер файла: такой же, как у ext2
- Максимальный размер тома: такой же, как у ext2
- Максимальное количество файлов: 2 32–1 (4 294 967 295)
- Максимальное количество файлов в каталоге: неограниченно
- Максимальный размер файла: 2 44–1 байт (16 ТиБ – 1)
- Максимальный размер тома: 2 48–1 байт (256 ТиБ – 1)
С точки зрения функциональности:
Имейте в виду, что в Linux, если у вас есть каталог со слишком большим количеством файлов, оболочка может не иметь возможности раскрывать подстановочные знаки. У меня проблема с фотоальбомом, размещенным в Linux. Он хранит все измененные изображения в одном каталоге. Хотя файловая система может обрабатывать множество файлов, оболочка не может.
С точки зрения скорости сервера:
Слишком много файлов в одном каталоге может привести к увеличению времени загрузки на несколько секунд. Наличие слишком большого количества каталогов также может увеличить время загрузки. (в этом играют роль характеристики вашего сервера)
С точки зрения SEO.
Я могу понять отсутствие правильных имен изображений из соображений безопасности (при условии, что пользователь загружает фотографии, а у вас есть переписывание на месте). Но вы действительно должны дать контенту релевантные имена (под)каталогов для лучшего поискового рейтинга и возможности частичного удалите URL-адреса, чтобы перейти в другое место на вашем сервере. (т.е. фотографии/на открытом воздухе/пейзаж/горы)
В конце концов, нет единого решения, которое подходит всем, но вы можете принять более взвешенное решение, основываясь на вышеупомянутом.
Если я отформатирую диск объемом 1 ТБ с параметрами по умолчанию, какое максимальное количество файлов я смогу хранить в корневом каталоге каждой файловой системы?
Редактировать: я искал информацию, но ни один из результатов не дал ответа на этот конкретный вопрос. Это были ответы на разницу между файловыми системами, максимальное количество файлов, которые можно на них хранить (включая файлы в подкаталогах), максимальный размер раздела и т.д.
Если бы я этого не сделал, я бы не спрашивал об этом здесь. Да, но я не нашел то, что искал. Все результаты поиска включали максимальный размер файловой системы, ограничения размера файла, ограничения количества файлов в папке, максимальное количество файлов и папок, максимальное количество символов в именах файлов и т. д. Ничего о том, сколько файлов я могу хранить в корневом каталоге каждого файловая система.
Это также сильно зависит от выбранного вами размера кластера, который зависит от файловой системы. Выберите 64 КБ в качестве размера кластера, и вы не сможете разместить столько файлов, сколько могли бы, например, с 12 КБ, потому что для размещения файла размером 32 КБ вы бы (теоретически) использовали весь кластер размером 64 КБ. На ваш вопрос нет однозначного ответа, потому что он не чисто математический. Если ваш диск является системным диском, а не диском хранения, он также изменит параметры, поскольку в первом случае, вероятно, будет сохранено некоторое пространство для системы. Метод форматирования тоже может многое изменить.
Этот теоретический диск является диском для хранения данных, и, как я объяснял выше, он будет отформатирован с использованием значений по умолчанию, которые ОС предлагает для каждой файловой системы. Я, как рядовой пользователь, вообще не знающий разницы между файловыми системами, ничего менять не стал бы. Я бы просто использовал диспетчер разделов ОС по умолчанию для форматирования диска.
Корневой каталог файловой системы — это просто еще одна папка. Таким образом, ответом будет максимальное количество файлов в папке.
1 Ответ 1
FAT12/16 — единственная файловая система с другими ограничениями на количество корневых каталогов и подкаталогов. Для большинства других файловых систем корневой каталог хранится так же, как и подкаталоги, и имеет такие же ограничения — если в корневом каталоге также хранятся файлы «метаданных», необходимо внести лишь незначительные изменения.
FAT12 и FAT16: различаются (очевидно, 64–512 распространены). Из Википедии: «Количество записей корневого каталога, доступных для FAT12 и FAT16, определяется при форматировании тома и сохраняется в 16-битном поле. Для заданного числа RDE и размера сектора SS количество RDS секторов корневого каталога RDS=ceil((RDE×32)/SS), и RDE обычно выбирается для заполнения этих секторов, т. е. RDE*32=RDS*SS. Носители FAT12 и FAT16 обычно используют 512 записей корневого каталога на негибких носителях. Некоторые сторонние инструменты, такие как mkdosfs, позволяют пользователю устанавливать этот параметр."
Обратите внимание, что FAT использует переменное количество записей для хранения длинных (не 8.3) имен файлов, поэтому фактическое максимальное количество элементов очень сильно зависит от того, как на самом деле названы ваши файлы. Каждое имя, не совместимое с 8.3, требует как минимум 1 запись LFN в дополнение к обычной записи 8.3, совместимой с DOS, и каждая из этих записей LFN содержит 13 символов. Таким образом, имя вроде "Hello world!.txt" будет стоить вам всего 3 слота.
FAT32: То же, что и обычный каталог.Согласно Википедии, «реализация Microsoft FAT32 накладывает искусственное ограничение в 65 535 записей в каталоге». Опять же, каждое имя, отличное от 8.3, должно храниться как несколько записей.
exFAT: В Википедии говорится: «Поддержка до 2 796 202 файлов в каталоге», ссылаясь на патент Microsoft. Как и в случае с FAT32, в exFAT нет ничего особенного в корневом каталоге, поэтому он имеет те же ограничения, что и подкаталоги. Однако exFAT лучше поддерживает длинные имена файлов.
NTFS: В другой ветке SU говорится: "Фиксированного ограничения нет. Максимальное количество файлов равно одному верхнему пределу. Это ограничение равно либо 2^23-1 (согласно многим реализациям драйверов), либо 2^48-1 ( в соответствии со структурой MFT_REF). Поскольку у вас будут БОЛЬШИЕ каталоги, вы увидите нерезидентные потоки $BITMAP_ALLOCATION, большой поток INDEX. Поток индекса, по сути, представляет собой дерево имен файлов B+."
Обратите внимание, что корневой каталог NTFS всегда содержит около 15 скрытых файлов, используемых для хранения метаданных файловой системы.
Ext2: из Википедии: «Теоретическое ограничение на количество файлов в каталоге составляет 1,3×10 20 , хотя это не имеет отношения к практическим ситуациям. […] Индексирование каталога недоступно. в ext2, поэтому возникают проблемы с производительностью для каталогов с большим количеством файлов (>10 000)."
Кроме того, Ext2 (и Ext3, но не Ext4) имеет ограничение на непосредственные подкаталоги в пределах одного каталога из-за не более 32000 ссылок на индексный дескриптор.
Ext4: из Википедии: «Чтобы обеспечить более крупные каталоги и непрерывную производительность, ext4 в Linux 2.6.23 и более поздних версиях по умолчанию включает индексы HTree (специализированная версия B-дерева), что позволяет использовать каталоги примерно до < em>10–12 миллионов записей для хранения в двухуровневом индексе HTree и ограничение размера каталога в 2 ГБ для размера блока в 4 КиБ в зависимости от длины имени файла. -level HTree и каталоги размером более 2 ГБ, что позволяет разместить около 6 миллиардов записей в одном каталоге."
Ext3: Честно говоря, я не уверен, где заканчивается Ext3 и начинается Ext4 — это может просто зависеть от того, какие функции включены. В Ext3 есть h-деревья (как и в Ext4), но нет функции «большой каталог».
Поскольку FAT и Ext2 используют линейные списки файлов, вы, вероятно, столкнетесь с проблемами производительности, прежде чем достигнете фактических ограничений на количество записей. Другие файловые системы используют более сложные структуры данных для более быстрого поиска файлов.
Читайте также: