Lösung 1:
Der Grund, warum man diese Art von Verzeichnisstruktur erstellen würde, ist, dass Dateisysteme eine Datei innerhalb eines Verzeichnisses finden müssen, und je größer das Verzeichnis ist, desto langsamer ist diese Operation.
Wie viel langsamer, hängt vom Design des Dateisystems ab.
Das ext4-Dateisystem verwendet einen B-Baum, um Verzeichniseinträge zu speichern. Eine Suche in dieser Tabelle dauert voraussichtlich O(log n) Zeit, die meistens weniger ist als die naive lineare Tabelle, die ext3 und frühere Dateisysteme verwendeten (und wenn dies nicht der Fall ist, ist das Verzeichnis zu klein, als dass es wirklich eine Rolle spielen könnte).
Das XFS-Dateisystem verwendet stattdessen einen B+-Baum. Der Vorteil gegenüber einer Hash-Tabelle oder einem B-Baum besteht darin, dass jeder Knoten mehrere Kinder b haben kann , wobei in XFS b variiert und kann bis zu 254 betragen (oder 19 für den Wurzelknoten; und diese Zahlen können veraltet sein). Das ergibt eine zeitliche Komplexität von O(logb n) , eine enorme Verbesserung.
Jedes dieser Dateisysteme kann Zehntausende von Dateien in einem einzigen Verzeichnis verarbeiten, wobei XFS in einem Verzeichnis mit der gleichen Anzahl von Inodes erheblich schneller ist als ext4. Aber Sie wollen wahrscheinlich kein einzelnes Verzeichnis mit 3M-Inodes, da selbst bei einem B+Tree die Suche einige Zeit dauern kann. Das hat überhaupt dazu geführt, Verzeichnisse auf diese Weise zu erstellen.
Was Ihre vorgeschlagenen Strukturen betrifft, ist die erste Option, die Sie angegeben haben, genau das, was in den nginx-Beispielen gezeigt wird. Es wird auf beiden Dateisystemen gut funktionieren, obwohl XFS immer noch einen kleinen Vorteil haben wird. Die zweite Option kann etwas besser oder etwas schlechter abschneiden, aber sie wird wahrscheinlich sogar bei Benchmarks ziemlich nah dran sein.
Lösung 2:
Meiner Erfahrung nach ist einer der Skalierungsfaktoren die Größe der Inodes bei einer Hash-Namen-Partitionierungsstrategie.
Beide von Ihnen vorgeschlagenen Optionen erstellen bis zu drei Inode-Einträge für jede erstellte Datei. Außerdem erstellen 732-Dateien einen Inode, der immer noch kleiner als die üblichen 16 KB ist. Für mich bedeutet dies, dass beide Optionen die gleiche Leistung erbringen.
Ich begrüße Sie zu Ihrem kurzen Hash; Frühere Systeme, an denen ich gearbeitet habe, haben die sha1sum der gegebenen Datei genommen und Verzeichnisse auf der Grundlage dieser Zeichenkette zusammengefügt, ein viel schwierigeres Problem.
Lösung 3:
Sicherlich wird jede Option dazu beitragen, die Anzahl der Dateien in einem Verzeichnis auf ein vernünftig erscheinendes Maß zu reduzieren, für xfs oder ext4 oder welches Dateisystem auch immer. Es ist nicht offensichtlich, was besser ist, müsste man testen, um es zu sagen.
Benchmarks mit Ihrer Anwendung, die so etwas wie die reale Arbeitslast simulieren, sind ideal. Andernfalls lassen Sie sich etwas einfallen, das speziell viele kleine Dateien simuliert. Apropos, hier ist eine Open-Source-Datei namens Smallfile. Seine Dokumentation verweist auf einige andere Tools.
hdparm anhaltendes I/O ist nicht so nützlich. Es zeigt nicht die vielen kleinen I/Os oder riesigen Verzeichniseinträge, die mit sehr vielen Dateien verbunden sind.