Solution 1 :
La raison pour laquelle on créerait ce type de structure de répertoires est que les systèmes de fichiers doivent localiser un fichier dans un répertoire, et plus le répertoire est grand, plus l'opération est lente.
Le ralentissement dépend de la conception du système de fichiers.
Le système de fichiers ext4 utilise un arbre B pour stocker les entrées de répertoire. Une recherche sur cette table devrait prendre O(log n) temps, qui est la plupart du temps inférieur à la table linéaire naïve utilisée par ext3 et les systèmes de fichiers précédents (et quand ce n'est pas le cas, le répertoire est trop petit pour que cela ait vraiment de l'importance).
Le système de fichiers XFS utilise à la place un arbre B+. L'avantage de ceci par rapport à une table de hachage ou un arbre B est que tout nœud peut avoir plusieurs enfants b , où dans XFS b varie et peut atteindre 254 (ou 19 pour le nœud racine; et ces nombres peuvent être obsolètes). Cela vous donne une complexité temporelle de O(logb n) , une grande amélioration.
Chacun de ces systèmes de fichiers peut gérer des dizaines de milliers de fichiers dans un seul répertoire, XFS étant nettement plus rapide que ext4 sur un répertoire avec le même nombre d'inodes. Mais vous ne voulez probablement pas un seul répertoire avec des inodes 3M, car même avec un arbre B +, la recherche peut prendre un certain temps. C'est ce qui a conduit à créer des répertoires de cette manière en premier lieu.
En ce qui concerne vos structures proposées, la première option que vous avez donnée est exactement ce qui est montré dans les exemples nginx. Il fonctionnera bien sur l'un ou l'autre système de fichiers, même si XFS aura toujours un petit avantage. La deuxième option peut fonctionner légèrement mieux ou légèrement moins bien, mais elle sera probablement assez proche, même sur les benchmarks.
Solution 2 :
D'après mon expérience, l'un des facteurs de mise à l'échelle est la taille des inodes compte tenu d'une stratégie de partitionnement par nom de hachage.
Les deux options que vous proposez créent jusqu'à trois entrées d'inode pour chaque fichier créé. De plus, 732 fichiers créeront un inode qui est toujours inférieur aux 16 Ko habituels. Pour moi, cela signifie que l'une ou l'autre des options fonctionnera de la même manière.
Je vous applaudis pour votre court hachage; les systèmes précédents sur lesquels j'ai travaillé ont pris la somme sha1 du fichier donné et des répertoires épissés en fonction de cette chaîne, un problème beaucoup plus difficile.
Solution 3 :
Certes, l'une ou l'autre option aidera à réduire le nombre de fichiers dans un répertoire à quelque chose qui semble raisonnable, pour xfs ou ext4 ou n'importe quel système de fichiers. Ce n'est pas évident ce qui est mieux, il faudrait tester pour le dire.
Une analyse comparative avec votre application simulant quelque chose comme la charge de travail réelle est idéale. Sinon, proposez quelque chose qui simule spécifiquement de nombreux petits fichiers. En parlant de ça, voici un open source appelé smallfile. Sa documentation fait référence à d'autres outils.
hdparm faire des E/S soutenues n'est pas aussi utile. Il n'affichera pas les nombreuses petites E/S ou les entrées de répertoire géantes associées à de très nombreux fichiers.