Есть ли ограничения на наличие большого количества файлов в каталоге в Mac OS X?


9

У меня в MacOS X более 100 000 файлов в каталоге, и, похоже, мой скрипт медленно читает в них файл.

Есть ли ограничение или рекомендация иметь столько файлов? Должен ли я разделить их на несколько каталогов?

Ограничение, которое я нашел, было то, что я не могу mv * fooдля всех 100 000 файлов. Это показывает ошибку, говоря «слишком длинный аргумент». Он работает с примерно менее 20000 файлов.


В настоящее время у меня есть 380 000 файлов в каталоге, и я понимаю, что даже открытие файла просто занимает более 10 секунд. Я решил разделить их на несколько каталогов.
Daisuki Honey

1
Файловая система HFS + должна иметь возможность хранить и обращаться к большому количеству файлов в каталоге по их полному имени без особых проблем. Но вы должны быть осторожны с подстановочными знаками. Когда вы используете *или ?как часть аргумента команды, операционная система ищет во всем каталоге соответствующие файлы (медленно), а затем заменяет ваш аргумент списком каждого соответствующего файла (долго), который затем передает команда. Вы могли бы сделать лучше с петлей или с несколькими командами мв, например, mv a* foo && mv b* foo.
Матиас Фрипп

Ответы:


1

Согласно этому ответу о переполнении стека и конкретным сведениям на сайте Apple , в отдельной папке может содержаться до 2,1 миллиарда элементов.

Тем не менее, тот факт, что он может содержать до 2,1 миллиарда элементов, не означает, что он может поддерживать производительность на этом уровне. Согласно Википедии ; Акцент мой

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

Таким образом, производительность естественным образом снижается благодаря тому, что файл каталога может использоваться только одной программой за раз. И если каталог увеличивается в размере, риск / ухудшение, вызванное этой проблемой, будет только возрастать; Чем больше файлов, тем больше у программ шансов получить доступ к файлам в этом одном каталоге. Дальнейшее подтверждение этой идеи здесь ; опять акцент мой

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


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

@DaisukiHoney Добро пожаловать! Поэтому, если вы нашли мой ответ полезным, не забудьте проголосовать за него. И если это был ответ, который решил вашу проблему, пожалуйста, не забудьте проверить его как таковой.
JakeGould

Да, определенно я голосую за твой ответ и проверь его. Еще раз большое спасибо.
Daisuki Honey

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

@poolie Вопрос касается каталога, который существует в файловой системе. Файл каталога существует для файловой системы, но сам каталог также существует в той же файловой системе. Это относится к вопросу, касающемуся более 10000 файлов в каталоге, который существует в одной файловой системе. Но этому вопросу более 2 лет, так что спасибо за ссылку в вики. Я обновил свой ответ, включив в него новую формулировку, а также прямую ссылку на данный раздел.
JakeGould

4

Короткий ответ: Хорошо, если вы читаете 100 000 файлов, я могу ожидать, что скрипт будет медленным.

Длинный ответ: Чтобы ответить на этот вопрос более подробно, вам нужно взглянуть на файловую систему на Mac. Mac используют HFS + ( Hierarchical File System Plus ), которая является современной файловой системой, которая имеет ограничения, но только в экстремальных ситуациях.

По моему опыту, это очень похоже на файловую систему журналирования Linux EXT. Он поддерживает монтирование каталогов, UNIX-подобные разрешения и т. Д. Он обращался к файлам в 32-разрядном формате, в соответствии с этим максимальное количество файлов может быть сохранено в томе 4 294 967 295, согласно этому источнику.

Файловая система начинает ломаться с файлами размером более 8 EB в современных системах и до 2,1 миллиарда файлов и папок в одном месте, как показано здесь .

Учитывая способ, которым HFS + - или действительно любая файловая система настроена в этом отношении - наличие большого количества файлов в папке не должно делать ничего «странного».

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


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

@DaisukiHoney Если вы работаете с таким количеством файлов, возможно, стоит посмотреть, сможете ли вы разбить вещи на каталоги. Это может быть сложно сделать на этом этапе, но может сделать вещи немного более стабильными в будущем.
JakeGould

@JakeGould Спасибо за совет. Я думал о реструктуризации, потому что я мог бы добавить еще несколько файлов. Спасибо.
Daisuki Honey
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.