Soluzione 1:
Il motivo per cui si creerebbe questo tipo di struttura di directory è che i filesystem devono individuare un file all'interno di una directory, e più grande è la directory, più lenta è l'operazione.
Quanto più lento dipende dal design del filesystem.
Il filesystem ext4 utilizza un albero B per memorizzare le voci della directory. Si prevede che una ricerca in questa tabella richieda O(log n) time, che la maggior parte delle volte è inferiore all'ingenua tabella lineare utilizzata da ext3 e dai filesystem precedenti (e quando non lo è, la directory è troppo piccola perché abbia davvero importanza).
Il filesystem XFS usa invece un albero B+. Il vantaggio di questo su una tabella hash o B-tree è che ogni nodo può avere più figli b , dove in XFS b varia e può arrivare fino a 254 (o 19 per il nodo radice; e questi numeri potrebbero non essere aggiornati). Questo ti dà una complessità temporale di O(logb n) , un grande miglioramento.
Ciascuno di questi filesystem può gestire decine di migliaia di file in una singola directory, con XFS che è significativamente più veloce di ext4 su una directory con lo stesso numero di inode. Ma probabilmente non vuoi una singola directory con inode 3M, poiché anche con un albero B + la ricerca può richiedere del tempo. Questo è ciò che ha portato alla creazione di directory in questo modo in primo luogo.
Per quanto riguarda le strutture proposte, la prima opzione che hai fornito è esattamente ciò che viene mostrato negli esempi di nginx. Funzionerà bene su entrambi i filesystem, anche se XFS avrà ancora un po' di vantaggio. La seconda opzione potrebbe funzionare leggermente meglio o leggermente peggio, ma probabilmente sarà abbastanza vicina, anche nei benchmark.
Soluzione 2:
Nella mia esperienza, uno dei fattori di ridimensionamento è la dimensione degli inode data una strategia di partizionamento del nome hash.
Entrambe le opzioni proposte creano fino a tre voci inode per ogni file creato. Inoltre, 732 file creeranno un inode che è ancora inferiore ai soliti 16 KB. Per me, questo significa che entrambe le opzioni funzioneranno allo stesso modo.
Ti applaudo per il tuo breve hash; i sistemi precedenti su cui ho lavorato hanno preso lo sha1sum del file specificato e le directory unite in base a quella stringa, un problema molto più difficile.
Soluzione 3:
Certamente entrambe le opzioni aiuteranno a ridurre il numero di file in una directory a qualcosa che sembra ragionevole, per xfs o ext4 o qualsiasi altro file system. Non è ovvio quale sia il migliore, bisognerebbe provare per dirlo.
Il benchmark con la tua applicazione che simula qualcosa come il vero carico di lavoro è l'ideale. Altrimenti, crea qualcosa che simuli specificamente molti piccoli file. A proposito, eccone uno open source chiamato smallfile. La sua documentazione fa riferimento ad altri strumenti.
hdparm fare I/O sostenuti non è così utile. Non mostrerà i molti piccoli I/O o le enormi voci di directory associate a moltissimi file.