Řešení 1:
Důvod, proč by se dal vytvořit tento druh adresářové struktury, je ten, že souborové systémy musí najít soubor v adresáři, a čím větší je adresář, tím je tato operace pomalejší.
O kolik pomalejší závisí na návrhu souborového systému.
Souborový systém ext4 používá k ukládání položek adresáře B-strom. Očekává se, že vyhledávání v této tabulce bude trvat O(log n) čas, který je většinou kratší než naivní lineární tabulka, kterou používaly ext3 a předchozí souborové systémy (a když tomu tak není, adresář je příliš malý na to, aby na něm skutečně záleželo).
Souborový systém XFS místo toho používá B+strom. Výhodou oproti hashovací tabulce nebo B-stromu je, že každý uzel může mít více potomků b , kde v XFS b se liší a může být až 254 (nebo 19 pro kořenový uzel; a tato čísla mohou být zastaralá). To vám dává časovou složitost O(logb n) , obrovské zlepšení.
Každý z těchto souborových systémů dokáže zpracovat desítky tisíc souborů v jednom adresáři, přičemž XFS je výrazně rychlejší než ext4 v adresáři se stejným počtem inodů. Pravděpodobně ale nechcete jediný adresář s 3M inody, protože i u B+stromu může vyhledávání nějakou dobu trvat. To je to, co vedlo k vytvoření adresářů tímto způsobem na prvním místě.
Pokud jde o vámi navrhované struktury, první možnost, kterou jste dali, je přesně to, co je zobrazeno v příkladech nginx. Bude fungovat dobře na obou souborových systémech, i když XFS bude mít stále trochu výhodu. Druhá možnost může fungovat o něco lépe nebo o něco hůře, ale pravděpodobně bude velmi blízko, a to i na základě benchmarků.
Řešení 2:
Podle mých zkušeností je jedním z faktorů škálování velikost inodů při rozdělování podle hash-name.
Obě vámi navržené možnosti vytvoří až tři položky inode pro každý vytvořený soubor. Také 732 souborů vytvoří inode, který je stále menší než obvyklých 16 kB. Pro mě to znamená, že obě možnosti budou fungovat stejně.
Tleskám vám za váš krátký hash; předchozí systémy, na kterých jsem pracoval, vzaly sha1sum daného souboru a spojily adresáře na základě tohoto řetězce, což je mnohem těžší problém.
Řešení 3:
Obě možnosti jistě pomohou snížit počet souborů v adresáři na něco, co se zdá rozumné, pro xfs nebo ext4 nebo jakýkoli jiný souborový systém. Není zřejmé, co je lepší, to by bylo nutné otestovat.
Ideální je benchmark s vaší aplikací simulující něco jako skutečnou zátěž. Jinak vymyslete něco, co konkrétně simuluje mnoho malých souborů. Když už o tom mluvíme, tady je open source s názvem smallfile. Jeho dokumentace odkazuje na některé další nástroje.
hdparm dělat trvalé I/O není tak užitečné. Neukáže mnoho malých I/O nebo obřích položek adresáře spojených s velmi mnoha soubory.