Es posible colocar todos los archivos en un directorio, aunque a veces puede ser un poco grande. Muchos sistemas de archivos tienen un límite . ¿Desea colocar un repositorio git en una unidad formateada FAT32 en una memoria USB? Solo puede almacenar 65.535 archivos en un solo directorio. Esto significa que es necesario subdividir la estructura del directorio para que sea menos probable llenar un solo directorio.
Esto incluso se convertiría en un problema con otros sistemas de archivos y repositorios git más grandes. Un repositorio de git relativamente pequeño que tengo colgado (aproximadamente 360MiB) y tiene 181,546 objetos para 11k archivos. Tire del repositorio de Linux y obtendrá 4,374,054 objetos. Si tuviera que poner todo esto en un directorio, sería imposible verificarlo y bloquearía (por algún significado de "bloqueo") el sistema de archivos.
¿Asi que? Lo divide por byte. Se realizan enfoques similares con aplicaciones como 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_
Más allá de esto, también se trata de una cuestión de rendimiento. Considere el rendimiento de NTFS con numerosos nombres largos de archivo :
Windows NT tarda mucho tiempo en realizar operaciones de directorio en unidades con formato del sistema de archivos de Windows NT (NTFS) que contienen una gran cantidad de archivos con nombres largos (nombres que no se ajustan a la convención 8.3) en un solo directorio.
Cuando NTFS enumera archivos en un directorio, tiene que buscar los nombres 8.3 asociados con los nombres largos de archivo. Debido a que un directorio NTFS se mantiene en un estado ordenado, los nombres de archivo largos correspondientes y los nombres 8.3 generalmente no están uno al lado del otro en la lista del directorio. Entonces, NTFS usa una búsqueda lineal del directorio para cada archivo presente. Como resultado, la cantidad de tiempo requerida para realizar un listado de directorio aumenta con el cuadrado del número de archivos en el directorio. Para pequeñas cantidades de archivos (menos de unos pocos cientos), el retraso de tiempo es insignificante. Pero a medida que el número de archivos en un directorio aumenta a varios miles, el tiempo requerido para realizar un listado puede aumentar a minutos, horas o incluso días. El problema se agrava si los nombres largos de archivo son muy similares y solo difieren en los últimos caracteres.
Con los archivos que llevan el nombre de las sumas de verificación SHA1, esto podría ser una receta para el desastre y el rendimiento abismal.
Si bien lo anterior es de una nota técnica de Windows NT 3.5 (y NTFS 1.2, comúnmente utilizado desde 1995 hasta principios de la década de 2000), esto también se puede ver en cosas como EXT3 con implementaciones del sistema de archivos que son listas enlazadas que requieren búsqueda O (n) . E incluso con ese cambio de árbol B:
Si bien el algoritmo HTree mejoró significativamente los tiempos de búsqueda, podría causar algunas regresiones de rendimiento para las cargas de trabajo que usaban readdir () para realizar alguna operación de todos los archivos en un directorio grande.
...
Una posible solución para mitigar este problema de rendimiento, que ha sido sugerido por Daniel Phillips y Andreas Dilger, pero que aún no se ha implementado, implica que el núcleo elija inodos libres cuyos números de inodo cumplan con una propiedad que agrupa los inodos por su hash de nombre de archivo. Daniel y Andreas sugieren asignar el inodo de un rango de inodes según el tamaño del directorio, y luego elegir un inodo libre de ese rango según el hash del nombre de archivo. En teoría, esto debería reducir la cantidad de sacudidas que resulta al acceder a los inodos a los que se hace referencia en el directorio en orden readdir. Sin embargo, no está claro que esta estrategia dé como resultado una aceleración; de hecho, podría aumentar el número total de bloques de inodo a los que podría tener que hacer referencia, y así empeorar el rendimiento de las cargas de trabajo readdir () + stat (). Claramente,
Por cierto, esta parte sobre cómo mejorar el rendimiento fue a partir de 2005, el mismo año en que se lanzó git.
Como se ve con Firefox y muchas otras aplicaciones que tienen muchos archivos hash en caché, el diseño de dividir el caché por byte. Tiene un costo de rendimiento insignificante, y cuando se usa multiplataforma con sistemas que pueden ser un poco anticuados, bien podría ser la diferencia entre que el programa funcione o no.