Système de fichiers grand nombre de fichiers dans un seul répertoire

OK, pas si grand mais j'ai besoin d'utiliser quelque chose où environ 60 000 fichiers d'une taille moyenne de 30 Ko sont stockés dans un seul répertoire (c'est une exigence donc ne peut pas simplement se diviser en sous-répertoires avec un plus petit nombre de fichiers).

Les fichiers seront accessibles de manière aléatoire, mais une fois créés, il n'y aura pas d'écriture sur le même système de fichiers. J'utilise actuellement Ext3 mais le trouve très lent. Aucune suggestion?

Vous devriez considérer XFS. Il prend en charge un très grand nombre de fichiers au niveau du système de fichiers et au niveau du répertoire, et les performances restent relativement cohérentes même avec un grand nombre d'entrées en raison des structures de données de l'arborescence B +.

Il y a une page sur leur wiki pour un grand nombre d'articles et de publications qui détaillent la conception. Je vous recommande de l'essayer et de le comparer à votre solution actuelle.

Un milliard de fichiers sous Linux

L'auteur de cet article explore certains des problèmes de performances sur les systèmes de fichiers avec un grand nombre de fichiers et fait de belles comparaisons des performances des différents systèmes de fichiers ext3, ext4 et XFS. Ceci est mis à disposition sous forme de diaporama. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

De nombreux fichiers dans un répertoire sur ext3 ont été longuement discutés sur le site sœur stackoverflow.com

À mon avis, 60 000 fichiers dans un répertoire sur ext3 sont loin d'être idéaux, mais en fonction de vos autres exigences, cela pourrait être suffisant.

D'ACCORD. J'ai fait quelques tests préliminaires en utilisant ReiserFS, XFS, JFS, Ext3 (dir_hash activé) et Ext4dev (noyau 2.6.26). Ma première impression a été que tous étaient assez rapides (sur mon poste de travail costaud) - il s'avère que la machine de production à distance a un processeur assez lent.

J'ai vécu une certaine bizarrerie avec ReiserFS même lors des tests initiaux, donc cela a été exclu. Il semble que JFS ait 33% moins de CPU que tous les autres et testera donc cela sur le serveur distant. S'il fonctionne assez bien, je vais l'utiliser.

J'écris une application qui stocke également des tas de fichiers bien que les miens soient plus gros et j'en ai 10 millions que je vais répartir sur plusieurs répertoires.

ext3 est lent principalement en raison de l'implémentation par défaut de la "liste chaînée". Donc, si vous avez beaucoup de fichiers dans un répertoire, cela signifie que l'ouverture ou la création d'un autre va devenir de plus en plus lente. Il existe quelque chose appelé un index htree qui est disponible pour ext3 et qui améliorerait considérablement les choses. Mais, il n'est disponible que lors de la création d'un système de fichiers. Voir ici: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Étant donné que vous devrez de toute façon reconstruire le système de fichiers et en raison des limitations ext3, ma recommandation est que vous envisagiez d'utiliser ext4 (ou XFS). Je pense que ext4 est un peu plus rapide avec des fichiers plus petits et a des reconstructions plus rapides. L'index Htree est par défaut sur ext4 pour autant que je sache. Je n'ai pas vraiment d'expérience avec JFS ou Reiser mais j'ai déjà entendu des gens le recommander.

En réalité, je testerais probablement plusieurs systèmes de fichiers. Pourquoi ne pas essayer ext4, xfs et jfs et voir lequel donne les meilleures performances globales?

Quelque chose qu'un développeur m'a dit qui peut accélérer les choses dans le code de l'application n'est pas de faire un appel "stat + open" mais plutôt "open + fstat". Le premier est nettement plus lent que le second. Je ne sais pas si vous avez un contrôle ou une influence sur cela.

Voir mon article ici sur stackoverflow. Stocker et accéder à jusqu'à 10 millions de fichiers sous Linux contient des réponses et des liens très utiles.

L'utilisation de tune2fs pour activer dir_index peut aider. Pour voir s'il est activé:

sudo tune2fs -l /dev/sda1 | grep dir_index

S'il n'est pas activé:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

Mais j'ai l'impression que vous vous trompez de chemin ... pourquoi ne pas générer un index plat et utiliser du code pour sélectionner au hasard en fonction de cela. Vous pouvez ensuite utiliser des sous-répertoires pour une structure arborescente plus optimisée.

ext3 et inférieur prennent en charge jusqu'à 32 768 fichiers par répertoire. ext4 prend en charge jusqu'à 65536 dans le nombre réel de fichiers, mais vous permettra d'en avoir plus (il ne les stockera tout simplement pas dans le répertoire, ce qui n'a pas d'importance pour la plupart des utilisateurs).

De plus, la façon dont les répertoires sont stockés sur les systèmes de fichiers ext * est essentiellement une grande liste. Sur les systèmes de fichiers plus modernes (Reiser, XFS, JFS), ils sont stockés sous forme d'arborescences B, qui sont beaucoup plus efficaces pour les grands ensembles.

Vous pouvez stocker des inodes de fichiers au lieu de noms de fichiers: l'accès aux numéros d'inodes devrait être beaucoup plus rapide que la résolution des noms de fichiers

Vous ne voulez pas entasser autant de fichiers dans un seul répertoire, vous voulez une sorte de structure. Même si c'est quelque chose d'aussi simple que d'avoir des sous-répertoires qui commencent par le premier caractère du fichier peut améliorer vos temps d'accès. Une autre astuce stupide que j'aime utiliser est de forcer le système à mettre à jour son cache avec des métainformations, c'est d'exécuter régulièrement updatedb. Dans une fenêtre exécutez slabtop, et dans une autre exécutez updatedb et vous verrez que beaucoup de mémoire va être allouée à la mise en cache. C'est beaucoup plus rapide de cette façon.

Vous n'avez pas spécifié le type de données dans ces fichiers. Mais d'après les sons, vous devriez utiliser une sorte de base de données avec indexation pour des recherches rapides.

Le système de fichiers n'est probablement pas le stockage idéal pour une telle exigence. Une sorte de stockage de base de données est meilleure. Pourtant, si vous ne pouvez pas l'aider, essayez de diviser les fichiers en plusieurs répertoires et utilisez unionfs pour monter (lier) ces répertoires sur un seul répertoire où vous souhaitez que tous les fichiers apparaissent. Je n'ai pas du tout utilisé cette technique pour accélérer, mais ça vaut le coup d'essayer.