Solución 1:
La razón por la que se crearía este tipo de estructura de directorios es que los sistemas de archivos deben ubicar un archivo dentro de un directorio, y cuanto más grande sea el directorio, más lenta será la operación.
Cuánto más lento depende del diseño del sistema de archivos.
El sistema de archivos ext4 utiliza un árbol B para almacenar entradas de directorio. Se espera que una búsqueda en esta tabla tome O(log n) tiempo, que la mayoría de las veces es menor que la tabla lineal ingenua que usaban ext3 y los sistemas de archivos anteriores (y cuando no lo es, el directorio es demasiado pequeño para que realmente importe).
El sistema de archivos XFS usa un árbol B+ en su lugar. La ventaja de esto sobre una tabla hash o un árbol B es que cualquier nodo puede tener varios hijos b , donde en XFS b varía y puede llegar a 254 (o 19 para el nodo raíz; y estos números pueden estar desactualizados). Esto le da una complejidad de tiempo de O(logb n) , una gran mejora.
Cualquiera de estos sistemas de archivos puede manejar decenas de miles de archivos en un solo directorio, siendo XFS significativamente más rápido que ext4 en un directorio con la misma cantidad de inodos. Pero probablemente no desee un solo directorio con inodos de 3M, ya que incluso con un árbol B+, la búsqueda puede llevar algún tiempo. Esto es lo que llevó a crear directorios de esta manera en primer lugar.
En cuanto a las estructuras propuestas, la primera opción que dio es exactamente lo que se muestra en los ejemplos de nginx. Funcionará bien en cualquier sistema de archivos, aunque XFS seguirá teniendo cierta ventaja. La segunda opción puede funcionar un poco mejor o un poco peor, pero probablemente estará bastante cerca, incluso en los puntos de referencia.
Solución 2:
En mi experiencia, uno de los factores de escala es el tamaño de los inodos dada una estrategia de partición de nombres hash.
Ambas opciones propuestas crean hasta tres entradas de inodo para cada archivo creado. Además, los archivos 732 crearán un inodo que aún es inferior a los 16 KB habituales. Para mí, esto significa que cualquier opción funcionará de la misma manera.
Te aplaudo por tu hash corto; los sistemas anteriores en los que he trabajado han tomado el sha1sum del archivo dado y los directorios empalmados basados en esa cadena, un problema mucho más difícil.
Solución 3:
Ciertamente, cualquiera de las opciones ayudará a reducir la cantidad de archivos en un directorio a algo que parezca razonable, para xfs o ext4 o cualquier sistema de archivos. No es obvio cuál es mejor, habría que probar para saberlo.
Comparar con su aplicación simulando algo así como la carga de trabajo real es ideal. De lo contrario, cree algo que simule muchos archivos pequeños específicamente. Hablando de eso, aquí hay uno de código abierto llamado smallfile. Su documentación hace referencia a otras herramientas.
hdparm hacer E/S sostenida no es tan útil. No mostrará las muchas E/S pequeñas o las entradas de directorio gigantes asociadas con muchos archivos.