Можно поместить все файлы в один каталог, хотя иногда это может стать немного большим. Многие файловые системы имеют ограничение . Вы хотите поместить репозиторий git на диск в формате FAT32 на флешку? Вы можете хранить только 65 535 файлов в одном каталоге. Это означает, что необходимо подразделить структуру каталогов так, чтобы заполнение одного каталога было менее вероятным.
Это может даже стать проблемой с другими файловыми системами и более крупными git-репозиториями. Относительно небольшой репозиторий Git, который я вывешивал (около 360 МБ), и он имеет 181 546 объектов для файлов размером 11 КБ. Потяните репозиторий Linux, и вы получите 4 374 054 объекта. Если бы вы поместили все это в один каталог, было бы невозможно проверить и вывести из строя (для некоторого значения «крах») файловую систему.
Так? Вы делите это на байт. Подобные подходы делаются с приложениями, такими как FireFox:
~/Li/Ca/Fi/Pr/7a/Cache $ ls
0/ 4/ 8/ C/ _CACHE_001_
1/ 5/ 9/ D/ _CACHE_002_
2/ 6/ A/ E/ _CACHE_003_
3/ 7/ B/ F/ _CACHE_MAP_
Помимо этого, это также касается вопроса производительности. Рассмотрим производительность NTFS с множеством длинных имен файлов :
Windows NT занимает много времени для выполнения операций с каталогами на дисках, отформатированных в файловой системе Windows NT (NTFS), которые содержат большое количество файлов с длинными именами файлов (имена, которые не соответствуют соглашению 8.3) в одном каталоге.
Когда NTFS перечисляет файлы в каталоге, она должна искать имена 8.3, связанные с длинными именами файлов. Поскольку каталог NTFS поддерживается в отсортированном состоянии, соответствующие длинные имена файлов и имена 8.3, как правило, не находятся рядом друг с другом в списке каталогов. Таким образом, NTFS использует линейный поиск в каталоге для каждого файла. В результате количество времени, необходимое для выполнения листинга каталога, увеличивается с квадратом количества файлов в каталоге. Для небольшого количества файлов (менее нескольких сотен) задержка незначительна. Но поскольку количество файлов в каталоге увеличивается до нескольких тысяч, время, необходимое для выполнения листинга, может увеличиться до минут, часов или даже дней. Проблема усугубляется, если длинные имена файлов очень похожи - отличаются только последними несколькими символами.
С файлами, названными в честь контрольных сумм SHA1, это может стать рецептом катастрофы и ужасной производительности.
Хотя приведенное выше взято из технической заметки Windows NT 3.5 (и NTFS 1.2 - обычно используемой с 1995 по начало 2000-х годов), это также можно увидеть в таких вещах, как EXT3, где реализации файловой системы представляют собой связанные списки, требующие поиска O (n) , И даже с этим изменением B-дерева:
Хотя алгоритм HTree значительно улучшил время поиска, он может привести к некоторым спадам производительности для рабочих нагрузок, использующих readdir () для выполнения некоторых операций со всеми файлами в большом каталоге.
...
Одно из возможных решений для смягчения этой проблемы производительности, которое было предложено Дэниелом Филлипсом и Андреасом Дилгером, но еще не реализовано, заключается в том, что ядро выбирает свободные иноды, номера инодов которых соответствуют свойству, которое группирует иноды по их хэшу имени файла. Дэниел и Андреас предлагают выделить инод из диапазона инодов на основе размера каталога, а затем выбрать свободный инод из этого диапазона на основе хэша имени файла. Теоретически это должно уменьшить количество изменений, возникающих при доступе к инодам, указанным в каталоге, в порядке чтения. Однако не ясно, что эта стратегия приведет к ускорению; фактически это может увеличить общее количество блоков inode, на которые, возможно, придется ссылаться, и, таким образом, ухудшить производительность рабочих нагрузок readdir () + stat (). Очевидно, что
Кстати, этот бит о том, как улучшить производительность, был с 2005 года, в том же году был выпущен git.
Как видно из Firefox и многих других приложений, которые имеют много файлов с хеш-кешированием, дизайн разбивает кэш по байтам. Он имеет незначительные затраты производительности, и при использовании кроссплатформенности с системами, которые могут быть немного устаревшими, вполне может быть разница между работающей программой или нет.