fichiers max par répertoire dans ext4

Je gère une application qui contient un magasin de fichiers dans lequel tous les fichiers sont stockés avec des noms de fichiers égaux à leurs sommes md5. Tous les fichiers sont stockés dans un répertoire. Actuellement, il y en a des milliers, mais bientôt il devrait y avoir des millions de fichiers sur le serveur. Le serveur actuel exécute Ubuntu 11.10 sur un système de fichiers ext4.

Quelqu'un m'a dit qu'il n'était pas judicieux de mettre de nombreux fichiers dans un répertoire, car cela entraînerait une augmentation significative du temps de recherche et de la fiabilité (il avait une histoire sur le nombre maximal de fichiers sur lesquels un seul répertoire pourrait pointer, résultant en une grande liste chaînée). Au lieu de cela, il a suggéré de créer des sous-répertoires avec par exemple des sous-chaînes du nom de fichier. Cependant, cela rendra certaines choses dans ma demande beaucoup plus lourdes.

Est-ce toujours vrai, ou les systèmes de fichiers modernes (par exemple, ext4) ont-ils des moyens plus efficaces pour gérer cela et évoluer naturellement? Wikipedia a quelques détails sur les systèmes de fichiers, mais il ne dit rien sur le nombre maximum de fichiers par répertoire, ni sur les temps de recherche.

Les ext3systèmes de fichiers et les versions ultérieures prennent en charge l' indexation des répertoires de l' arborescence B hachée . Cela évolue très bien tant que les seules opérations que vous effectuez sont l'ajout, la suppression et l'accès par nom. Cependant, je recommanderais toujours de décomposer les répertoires. Dans le cas contraire, vous créez un piège dangereux pour les outils ( updatedb, ls, du, etc.) qui effectuent d' autres opérations sur les répertoires qui peuvent exploser si le répertoire a trop d'entrées.

Le cœur du problème est de fouiller dans l'inode du répertoire pour le fichier que vous voulez. Certains systèmes de fichiers le font mieux que d'autres. Certains se rapprochent des milliards, mais si vous ne disposez que de 20 000 fichiers, accéder à ces fichiers est nettement plus rapide. De plus, un grand nombre de fichiers crée des problèmes pour certains outils et peut en conséquence rendre la sauvegarde / restauration un problème beaucoup plus difficile.

En l'occurrence, j'ai rencontré exactement le même problème dans notre propre développement (md5sum en tant que nom de fichier, mise à l'échelle de celui-ci). Ce que j'ai recommandé à nos développeurs, c'est de couper la chaîne en morceaux. Ils sont allés avec des groupes de 4, mais sur le système de fichiers sur lequel nous étions à l'époque, même si beaucoup se révélaient problématiques du point de vue des performances, ils ont donc fini par se diviser en groupe de 3 pour les 6 premiers triplets et laisser le reste comme le nom de fichier dans le répertoire du terminal.

Groupe de 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Groupe de 3:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Cela a l'avantage de conserver des tailles de répertoire réduites, et puisque MD5sum est assez aléatoire, cela créera des arborescences de répertoires équilibrées. Il est peu probable que ce dernier répertoire contienne plus de quelques fichiers. Et ce n'était pas si difficile de travailler dans notre code. Nous travaillons avec plusieurs millions de projets de fichiers, donc la mise à l'échelle était très importante pour nous.

Les systèmes de fichiers modernes gèrent très bien les très gros répertoires, même pour des millions de fichiers. Mais les outils conventionnels ne le font pas. Par exemple, répertorier un répertoire aussi volumineux avec "ls" prendrait beaucoup de temps car il lirait normalement l'intégralité du répertoire et le trierait (bien que vous puissiez utiliser ls -f pour éviter le tri). Il ne commencerait pas à afficher les fichiers avant qu'ils ne soient tous lus. La division des noms est utile dans certains cas, mais pas dans tous (par exemple, la réplication rsync peut encore avoir besoin de collecter l'arborescence complète des noms).

Puis-je suggérer d'utiliser une base de données SQL à la place? Cela transformerait probablement cette faiblesse perçue dans votre application en force.