Bug dans l'implémentation de la fonctionnalité ext4 dir_index que vous utilisez sur votre système de fichiers de destination.
Solution :recréer le système de fichiers sans dir_index. Ou désactivez la fonctionnalité à l'aide de tune2fs (une certaine prudence est requise, voir le lien connexe Novell SuSE 10/11 :Désactiver l'indexation H-Tree sur un système de fichiers ext3 qui, bien que lié à ext3 peut nécessiter la même prudence.
(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)
- ext4 :Erreurs mystérieuses "Pas d'espace disponible sur l'appareil"
ext4 a une fonctionnalité appelée dir_index activée par défaut, qui est assez sensible aux collisions de hachage.
......
ext4 a la possibilité de hacher les noms de fichiers de son contenu. Cela améliore les performances, mais présente un "petit" problème :ext4 ne développe pas sa table de hachage lorsqu'elle commence à se remplir. Au lieu de cela, il renvoie -ENOSPC ou "pas d'espace disponible sur l'appareil".
Suggestions de choix meilleurs qu'ext4 pour stocker des masses de petits fichiers :
Si vous utilisez le système de fichiers comme magasin d'objets, vous voudrez peut-être envisager d'utiliser un système de fichiers spécialisé dans ce domaine, éventuellement au détriment d'autres caractéristiques. Une recherche rapide sur Google a trouvé Ceph , qui semble être open source et peut être monté en tant que système de fichiers POSIX, mais également accessible avec d'autres API. Je ne sais pas si cela vaut la peine de l'utiliser sur un seul hôte, sans profiter de la réplication.
Un autre système de stockage d'objets est Swift d'OpenStack . Ses documents de conception indiquent qu'il stocke chaque objet dans un fichier séparé, avec des métadonnées dans xattrs. Voici un article à ce sujet. Leur guide de déploiement indique qu'ils ont trouvé que XFS offrait les meilleures performances pour le stockage d'objets. Ainsi, même si la charge de travail n'est pas ce que XFS est le meilleur, il était apparemment meilleur que les concurrents lorsque RackSpace testait des choses. Il est possible que Swift favorise XFS car XFS a un support bon/rapide pour les attributs étendus. Il se peut que ext3/ext4 fasse l'affaire sur des disques uniques en tant que backend de magasin d'objets si des métadonnées supplémentaires n'étaient pas nécessaires (ou si elles étaient conservées dans le fichier binaire).
Swift fait la réplication / l'équilibrage de charge pour vous et vous suggère de lui donner des systèmes de fichiers créés sur des disques bruts, pas RAID . Il souligne que sa charge de travail est essentiellement le pire des cas pour RAID5 (ce qui est logique si nous parlons d'une charge de travail avec des écritures de petits fichiers. XFS ne les emballe généralement pas tout à fait tête à queue, donc vous ne obtenir des écritures sur toute la bande, et RAID5 doit faire quelques lectures pour mettre à jour la bande de parité.Les documents Swift parlent également de l'utilisation de 100 partitions par lecteur.Je suppose que c'est un terme Swift, et ne parle pas de créer 100 systèmes de fichiers XFS différents sur chacun Disque SATA.
L'exécution d'un XFS distinct pour chaque disque est en fait une énorme différence . Au lieu d'un gigantesque carte free-inode, chaque disque aura un XFS séparé avec des listes libres séparées. De plus, cela évite la pénalité RAID5 pour les petites écritures.
Si vous avez déjà votre logiciel conçu pour utiliser un système de fichiers directement comme magasin d'objets, plutôt que de passer par quelque chose comme Swift pour gérer la réplication / l'équilibrage de charge, vous pouvez au moins éviter d'avoir tous vos fichiers dans un seul répertoire. (Je n'ai pas vu les documents Swift dire comment ils disposent leurs fichiers dans plusieurs répertoires, mais je suis certain qu'ils le font.)
Avec presque tous les systèmes de fichiers normaux, il sera utile d'utiliser une structure comme
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
Environ 10 000 entrées sont probablement raisonnables, donc prendre 4 caractères bien répartis de vos noms d'objets et les utiliser comme répertoires est une solution simple. Il n'a pas besoin d'être très bien équilibré. Le répertoire impair de 100k ne sera probablement pas un problème notable, et certains répertoires vides non plus.
XFS n'est pas idéal pour les masses énormes de petits fichiers. Il fait ce qu'il peut, mais il est plus optimisé pour les écritures en continu de fichiers plus volumineux. C'est très bon dans l'ensemble pour une utilisation générale, cependant. Il n'a pas ENOSPC sur les collisions dans son indexation de répertoire (AFAIK), et peut gérer avoir un répertoire avec des millions d'entrées. (Mais il est toujours préférable d'utiliser au moins un arbre à un niveau.)
Dave Chinner a fait quelques commentaires sur les performances de XFS avec un grand nombre d'inodes alloués, conduisant à un touch plutôt lent performance. Trouver un inode libre à allouer commence à prendre plus de temps CPU, car le bitmap d'inode libre est fragmenté. Notez qu'il ne s'agit pas d'un problème d'un seul grand répertoire par rapport à plusieurs répertoires, mais plutôt d'un problème de nombreux inodes utilisés sur l'ensemble du système de fichiers. Le fractionnement de vos fichiers en plusieurs répertoires aide à résoudre certains problèmes, comme celui sur lequel ext4 s'est étouffé dans l'OP, mais pas le problème du disque entier consistant à garder une trace de l'espace libre. Le système de fichiers séparé par disque de Swift aide à cela, par rapport au géant XFS sur un RAID5.
Je ne sais pas si btrfs est bon à cela, mais je pense qu'il peut être. Je pense que Facebook emploie son développeur principal pour une raison. :P Certains benchmarks que j'ai vus, comme le détarrage d'une source du noyau Linux, montrent que btrfs fonctionne bien.
Je connais reiserfs a été optimisé pour ce cas, mais il est à peine, voire pas du tout, maintenu. Je ne peux vraiment pas recommander d'aller avec reiser4. Il pourrait être intéressant d'expérimenter, cependant. Mais c'est de loin le choix le moins pérenne. J'ai également vu des rapports de dégradation des performances sur reiserFS vieillissant, et il n'y a pas de bon outil de défragmentation. (google filesystem millions of small files , et regardez quelques-unes des réponses existantes sur stackexchange.)
Il me manque probablement quelque chose, donc dernière recommandation :posez des questions à ce sujet sur serverfault ! Si je devais choisir quelque chose maintenant, je dirais d'essayer BTRFS, mais assurez-vous d'avoir des sauvegardes. (en particulier si vous utilisez la redondance de plusieurs disques intégrée de BTRFS, au lieu de l'exécuter sur RAID. Les avantages en termes de performances pourraient être importants, car les petits fichiers sont une mauvaise nouvelle pour RAID5, à moins qu'il ne s'agisse d'une charge de travail principalement en lecture.)
Pour ce problème ci-dessous, voici ce que j'ai fait pour résoudre (vous aurez peut-être besoin d'un accès sudo pour les étapes ci-dessous) :
-
L'espace utilisé des inodes était de 100 %, ce qui peut être récupéré à l'aide de la commande ci-dessous
df -i /
Inodes du système de fichiers IUsed IFree IUse% Monté sur
/dev/xvda1 524288 524288 o 100% /
- Besoin de libérer l'iNoted, donc besoin de trouver les fichiers qui ont ici le nombre de nœuds i en utilisant la commande ci-dessous :
Essayez de trouver s'il s'agit d'un problème d'inodes avec :
df -ih
Essayez de trouver des dossiers racine avec un grand nombre d'inodes :
for i in /*; do echo $i; find $i |wc -l; done
Essayez de trouver des dossiers spécifiques :
for i in /src/*; do echo $i; find $i |wc -l; done
- nous avons maintenant mis à zéro le dossier contenant un grand nombre de fichiers. Exécutez les commandes ci-dessous l'une après l'autre pour éviter toute erreur (dans mon cas, le dossier réel était /var/spool/clientmqueue) :
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +