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


29

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?


3
Pourquoi doivent-ils être dans un seul répertoire?
Kyle Brandt

1
Je suis également intéressé par une réponse à jour à la question d'origine, étant donné suffisamment d'améliorations dans xfs et ext4.

Réponses:


15

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.


selon les diapositives de la réponse de @ nelaar, ext4 serait supérieur à xfs pour cette tâche.
mulllhausen

13

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

il est temps d'exécuter mkfs il est temps de créer des fichiers de 1M 50kb Temps de réparation du système de fichiers suppression de 1 million de fichiers


2
Nous préférons vraiment que les réponses contiennent du contenu et non des pointeurs vers le contenu. Bien que cela puisse théoriquement répondre à la question, il serait préférable d'inclure ici les parties essentielles de la réponse et de fournir le lien de référence.
user9517 prend en charge GoFundMonica

@Iain j'espère que c'est mieux, car le simple téléchargement du PDF vous donnera les mêmes informations.
nelaaro

19
wow ce sont des graphiques exceptionnellement difficiles à lire. ~
ThorSummoner

8

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.


5

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.


5

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.


3

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.


1
était /dev/sad1intentionnel pour éviter les erreurs de copie / pâtes?
Anwar

2

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.


2
prendre en charge ce nombre de fichiers dans un répertoire n'est pas la même chose que le faire à une vitesse raisonnable. Je ne sais pas encore si ext4 est meilleur, mais ext3 ralentit considérablement lorsqu'il a plus de quelques milliers de fichiers dans un répertoire, même avec dir_index activé (cela aide, mais n'élimine pas complètement le problème).
cas

1

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


Maintenant dis-moi. Comment ouvrir un fichier par numéro d'inode?
Matt

1
@Matt, il semble que la question ait changé après avoir répondu. Ou j'étais beaucoup plus stupide il y a 1,5 ans :)))
kolypto

0

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.


-1

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.


-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.