Есть ли ограничение на число файлов в определенной папке?
сколько файлов может содержать папка? У меня 30К папок в папке 1. Каждая из папок имеет 1 файл изображения. Есть ли ограничение на количество файлов в папке может храниться?
Я использую Windows Server 2003, IIS6.
4 ответов
Примечание: предполагая NTFS, так как никто в здравом уме не будет использовать FAT ни для чего другого, кроме USB-накопителей или карт памяти, не говоря уже о сервере (ok, это мысль-это страшно).
Да, есть предел. Хранение большего количества файлов, чем частиц во Вселенной, может оказаться непрактичным. Однако фактический предел значительно меньше.
NTFS имеет максимум 4,294,967,295 (2 32 — 1) файлов на томе. Некоторые из них уже используются самой файловой системой, и папка также должна считаться файлами.
30,000 не так уж много файлов. Но Microsoft рекомендует что ты выключить автоматическое создание DOS-совместимых коротких имен, если вы двигаетесь мимо 300,000, как найти уникальное короткое имя становится трудно, то.
там нет практических ограничений на объединенные размеры всех файлов в папке, хотя могут быть ограничения на количество файлов в папке. Что еще более важно, существуют ограничения на размер отдельных файлов, которые зависят от того, какую файловую систему вы используете на жестком диске. («Файловая система» — это не что иное, как спецификация того, как именно файлы хранятся на диске.)
разберем по файловой системе:
•жир aka FAT16
жир, для таблицы распределения файлов, является преемником оригинальной файловой системы FAT12, поставляемой с MS-DOS много, много лет назад.
Maximum максимальный размер диска: 4 гигабайта
◦максимальный размер файла: 4 ГБ
◦максимальное количество файлов на диске: 65,517
Maximum максимальное количество файлов в одной папке: 512 (если я правильно помню, корневая папка «/» имела нижний предел 128).
•FAT32
» там нет практических лимит на общий размер всех файлов в папке, хотя там может быть ограничения на количество файлов в папке.»FAT32 был введен для преодоления некоторых ограничений FAT16.
◦максимальный размер диска: 2 ТБ
◦максимальный размер файла: 4 ГБ
◦максимальное количество файлов на диске: 268,435,437
◦максимальное количество файлов в одной папке: 65 534
•NTFS
NTFS, или » новая технология Файловая система», введенная в Windows NT, является полностью переработанной файловой системой.
◦максимальный размер диска: 256 терабайт
◦максимальный размер файла: 256 терабайт
◦максимальное количество файлов на диске: 4,294,967,295
◦максимальное число файлов в одной папке: 4,294,967,295
обратите внимание, что когда я говорю «диск» выше, я действительно говорю о «логических» дисках, не обязательно физических. Никто не делает 256 терабайт диск, но с помощью NTFS массив дисков можно рассматривать как один логический диск. Предположительно, если у вас их достаточно, вы можете построить огромный логический диск.
Также обратите внимание, что ограничение NTFS в 256 терабайт вполне может быть просто ограничение реализации — я читал, что формат NTFS может поддерживать диски до 16 эксабайт (16 раз 1,152,921,504,606,846,976 байт).
Есть ли ограничение на количество открытых файлов в Windows
Я открываю много файлов с помощью fopen() в VC++, но через некоторое время это удается.
существует ли ограничение на количество файлов, которые вы можете открыть одновременно?
7 ответов
библиотеки времени выполнения C имеют ограничение 512 для количества файлов, которые могут быть открыты в любой момент времени. Попытка открыть больше максимального количества файловых дескрипторов или файловых потоков приводит к сбою программы. Использовать _setmaxstdio изменить это число. Более подробную информацию об этом можно прочитать здесь
Также вам может потребоваться проверить, поддерживает ли ваша версия windows верхний предел, который вы пытаетесь установить с помощью _setmaxstdio . Для получения дополнительной информации о _setmaxstdio Регистрация здесь
информация по этому вопросу, соответствующая VS 2015, может быть найдена здесь
Если вы используете стандартные библиотеки POSIX C / C++ с Windows, ответ «да», есть предел.
однако, что интересно, ограничение накладывается типом библиотек C / C++, которые вы используете.
я наткнулся на следующий поток JIRA (http://bugs.mysql.com/bug.php?id=24509) из MySQL. Они имели дело с той же проблемой о количестве открытых файлов.
однако Пол Дюбуа объяснил, что проблема может эффективно устраняется в Windows с помощью .
вызовы Win32 API (CreateFile(), WriteFile () и так далее) и максимальное количество открытых файлов по умолчанию был увеличен до 16384. Этот максимум можно увеличить дальше мимо использование параметра —max-open-files=N в запуск сервера.
естественно, у вас может быть теоретически большое количество открытых файлов, используя метод, подобный пулу подключений к базе данных, но это будет иметь строгое влияние на представлении.
действительно, открытие большого количества файлов может быть плохой дизайн. Однако некоторые ситуации требуют этого. Например, если вы создаете сервер баз данных, который будет использоваться тысячами пользователей или приложений, серверу обязательно придется открыть большое количество файлов (или пострадать от снижения производительности с помощью методов пула файловых дескрипторов).
в случае, если кто-то еще неясен относительно того, к чему применяется предел, я считаю, что это предел для каждого процесса, а не для всей системы.
Я просто написал небольшую тестовую программу для открытия файлов, пока она не выйдет из строя. Он попадает в 2045 файлов перед сбоем (2045 + STDIN + STDOUT + STDERROR = 2048), затем я оставил это открытым и запустил другую копию.
вторая копия показала такое же поведение, то есть у меня было по крайней мере 4096 файлов, открытых сразу.
Да есть ограничения в зависимости от уровня доступа, который вы используете при открытии файлов. Вы можете использовать _getmaxstdio найти пределы и _setmaxstdio изменить ограничения.
Я не знаю, откуда Пауло взял этот номер.. В операционных системах на базе windows NT количество дескрипторов файлов, открытых для каждого процесса, в основном ограничено физической памятью — это, безусловно, сотни тысяч.
предел зависит от ОС, и доступной памяти.
в старом Д. С. О. предел 255 simultaneuously открытых файлов.
в Windows XP предел выше (я считаю, что это 2,048, как указано MSDN).
столкнулся с той же проблемой, но с использованием Embarcadero C++-Builder из RAD Studio 10.2. C-время выполнения этой вещи, похоже, не обеспечивает _getmaxstdio или _setmaxstdio , но некоторые макрос и их предел по умолчанию намного ниже, чем сказано здесь для других сред выполнения:
Производительность NTFS и большие объемы файлов и каталогов
Как Windows с NTFS работает с большими объемами файлов и каталогов?
есть ли какие-либо указания относительно ограничений файлов или каталогов, которые вы можете разместить в одном каталоге, прежде чем запускать проблемы с производительностью или другие проблемы? например, папка с папками 100,000 внутри нее-это хорошо, что нужно сделать
7 ответов
вот некоторые советы от кого-то со средой, где у нас есть папки, содержащие десятки миллионов файлов.
- папка хранит информацию об индексе (ссылки на дочерние файлы и дочернюю папку) в индексном файле. Этот файл станет очень большим, когда у вас будет много детей. Обратите внимание, что он не различает ребенка, который является папкой, и ребенка, который является файлом. Единственное различие заключается в том, что содержимое этого ребенка является либо индексом папки ребенка, либо данные файла ребенка. Примечание: Я несколько упрощаю это, но это получает точку зрения.
- индексный файл будет фрагментирован. Когда она становится слишком фрагментированным, вы не сможете добавлять файлы в эту папку. Это потому, что есть ограничение на # фрагментов, которые разрешены. Это по замыслу. Я подтвердил это с Microsoft в вызове инцидента поддержки. Поэтому, хотя теоретический предел количества файлов, которые вы можете иметь в папке, составляет несколько миллиардов, удачи при запуске ударяя десятки миллионов файлов, как вы нажмете ограничение фрагментации в первую очередь.
- однако не все так плохо. Вы можете использовать инструмент:contig.exe для дефрагментации этого индекса. Это не уменьшит размер индекса (который может достигать нескольких гигабайт для десятков миллионов файлов), но вы можете уменьшить количество фрагментов. Примечание: средство дефрагментации диска не будет дефрагментировать индекс папки. Он будет дефрагментировать данные файла. Только contig.exe инструмент будет дефрагментировать индекс. FYI: вы также можно использовать для дефрагментации данных отдельного файла.
- Если вы дефрагментируете, не ждите, пока не достигнете максимального # предела фрагмента. У меня есть папка, где я не могу дефрагментировать, потому что я ждал, пока не станет слишком поздно. Мой следующий тест — попытаться переместить некоторые файлы из этой папки в другую папку, чтобы увидеть, могу ли я дефрагментировать ее. Если это не удастся, то мне нужно будет сделать 1) создать новую папку. 2) переместить группу файлов в новую папку. 3) дефрагментация новой папки. повторяйте #2 & #3 до это делается, а затем 4) удалите старую папку и переименуйте новую папку в соответствии со старой.
чтобы ответить на ваш вопрос более прямо: Если вы смотрите на записи 100K, не беспокойтесь. Иди развлекайся. Если вы смотрите на десятки миллионов записей, то либо:
a) планируйте разделить их на подпапки (например, скажем, у вас есть файлы 100M. Лучше хранить их в 1000 папках, чтобы у вас было только 100 000 файлов в папке, чем хранить их в 1 большую папку. Это создаст 1000 индексов папок вместо одного большого, который с большей вероятностью достигнет максимального предела фрагментов или
b) планируйте запустить contig.exe на регулярной основе, чтобы сохранить дефрагментацию индекса вашей большой папки.
читайте ниже, только если вам скучно.
фактический предел не на # фрагмента, а на количество записей сегмента данных, в котором хранятся указатели на фрагмент.
Итак, у вас есть сегмент данных, в котором хранятся указатели на фрагменты данных каталога. В данных каталога хранится информация о подкаталогах и вложенных файлах, которые предположительно хранятся в каталоге. На самом деле каталог ничего не «хранит». Это просто функция отслеживания и представления, которая представляет иллюзию иерархии для пользователя, поскольку сам носитель является линейным.
существуют также проблемы с производительностью при создании коротких имен файлов, замедляющих работу. Корпорация Майкрософт рекомендует отключить создание коротких файлов, если у вас более 300k файлов в папке [1]. Чем менее уникальны первые 6 символов, тем больше это проблема.
Я создаю файловую структуру для размещения до 2 миллиардов (2^32) файлов и выполнил следующие тесты, которые показывают резкое падение производительности навигации + чтения примерно в 250 файлах или 120 каталогах на каталог NTFS на твердотельном диске (SSD):
- производительность файла падает на 50% между 250 и 1000 файлов.
- производительность каталога падает на 60% между 120 и 1000 каталогами.
- значения для чисел > 1000 остаются относительно стабильными
интересно, что количество каталогов и файлов существенно не вмешивается.
- номера файлов выше 250 стоят в 2 раза
- каталоги выше 120 стоят в 2,5 раза
- файл-проводник в Windows 7 может обрабатывать большие # файлы или #Dirs, но удобство использования по-прежнему плохо.
- введение подкаталогов не дорого
Это данные (2 Измерения для каждого файла и каталога):
и это тестовый код:
100,000 должно быть нормально.
Я (анекдотально) видел людей, имеющих проблемы со многими миллионами файлов, и у меня были проблемы с Explorer, просто не имея понятия, как считать последние 60-что-то тысяч файлов, но NTFS должен быть хорош для томов, о которых вы говорите.
в случае, если вам интересно, технический (и я надеюсь теоретической) максимальное количество файлов: 4,294,967,295
для локального доступа большое количество каталогов / файлов не кажется проблемой. Однако, если вы обращаетесь к нему по сети, есть заметный удар по производительности после нескольких сотен (особенно при доступе с компьютеров Vista (XP к Windows Server w/NTFS, похоже, работает намного быстрее в этом отношении)).
при создании папки с N записями создается список из N элементов на уровне файловой системы. Этот список представляет собой общесистемную общую структуру данных. Если вы начнете постоянно изменять этот список, добавляя / удаляя записи, я ожидаю, по крайней мере, некоторого конфликта блокировки по общим данным. Это утверждение — теоретически — может негативно повлиять на производительность.
для сценариев только для чтения я не могу представить никакой причины для снижения производительности каталогов с большими количество записей.
У меня был реальный опыт работы с около 100 000 файлов (каждый несколько Мб) на NTFS в каталоге при копировании одной онлайн-библиотеки.
для открытия каталога с помощью Explorer или 7-zip требуется около 15 минут.
запись копии сайта с помощью winhttrack всегда будет застрять через некоторое время. Он также имел дело с каталогом, содержащим около 1 000 000 файлов. Я думаю, что хуже всего то, что MFT может только последовательно проходить.
открытие того же под ext2fsd на ext3 дали почти такое же время. Вероятно, переход на reiserfs (не reiser4fs) может помочь.
попытка избежать этой ситуации, вероятно, лучше всего.
для ваших собственных программ, использующих blobs без каких-либо fs, может быть полезно. Вот так Facebook для хранения фотографий.