Comment corriger les erreurs intermittentes «Il n'y a plus d'espace sur l'appareil» pendant le MV lorsque l'appareil a beaucoup d'espace?
- Ubuntu 14.04 sur un bureau
- Lecteur source:/dev/sda1: 5 To ext4 single
volume du lecteur - Volume cible:/dev/mapper/archive-lvarchive: raid6 (mdadm) 18 To de volume avec lvm
partition et ext4
Il y a environ 15 millions de fichiers à déplacer, et certains peuvent être des doublons (je ne veux pas écraser les doublons).
La commande utilisée (à partir du répertoire source) était:
ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}
Cela dure depuis quelques jours comme prévu, mais je reçois l'erreur d'augmenter la fréquence. Lorsqu'il a démarré, le lecteur cible était rempli à environ 70%, maintenant il est à environ 90%. Auparavant, environ 1/200 des mouvements indiquaient et des erreurs, maintenant c'est environ 1/5. Aucun des fichiers ne dépasse 100 Mo, la plupart font environ 100 Ko
Quelques informations:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb3 155G 5.5G 142G 4% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 797M 2.9M 794M 1% /run
none 5.0M 4.0K 5.0M 1% /run/lock
none 3.9G 0 3.9G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sdb1 19G 78M 18G 1% /boot
/dev/mapper/archive-lvarchive 18T 15T 1.8T 90% /mnt/archive
/dev/sda1 4.6T 1.1T 3.3T 25% /mnt/tmp
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb3 10297344 222248 10075096 3% /
none 1019711 4 1019707 1% /sys/fs/cgroup
udev 1016768 500 1016268 1% /dev
tmpfs 1019711 1022 1018689 1% /run
none 1019711 5 1019706 1% /run/lock
none 1019711 1 1019710 1% /run/shm
none 1019711 2 1019709 1% /run/user
/dev/sdb1 4940000 582 4939418 1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539 16% /mnt/archive
/dev/sda1 152621056 5391544 147229512 4% /mnt/tmp
Voici ma sortie:
mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd
J'ai trouvé BEAUCOUP de messages sur cette erreur, mais le pronostic ne correspond pas. Des problèmes tels que "votre lecteur est réellement plein" ou "vous avez manqué d'inodes" ou même "votre/volume de démarrage est plein". La plupart du temps, cependant, ils traitent avec des logiciels tiers provoquant un problème en raison de la façon dont il gère les fichiers, et ils sont tous constants, ce qui signifie que chaque mouvement échoue.
Merci.
EDIT: voici un exemple de fichier ayant échoué et réussi:
ÉCHEC (toujours sur le lecteur source)
ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf
RÉUSSITE (Sur le volume cible)
ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf
De plus, bien que tous les fichiers n'échouent pas, un fichier qui échoue échouera TOUJOURS. Si je recommence encore et encore, c'est cohérent.
EDIT: quelques commandes supplémentaires par demande de @mjturner
$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir
$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /mnt/archive
Filesystem UUID: af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 289966080
Block count: 4639456256
Reserved block count: 231972812
Free blocks: 1274786115
Free inodes: 256343444
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 2048
Inode blocks per group: 128
RAID stride: 128
RAID stripe width: 512
Flex block group size: 16
Filesystem created: Thu Jun 25 12:05:12 2015
Last mount time: Mon Aug 3 18:49:29 2015
Last write time: Mon Aug 3 18:49:29 2015
Mount count: 8
Maximum mount count: -1
Last checked: Thu Jun 25 12:05:12 2015
Check interval: 0 (<none>)
Lifetime writes: 24 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup: inode blocks
$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name: <none>
Last mounted on: /mnt/tmp
Filesystem UUID: 10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 152621056
Block count: 1220942336
Reserved block count: 61047116
Free blocks: 367343926
Free inodes: 135953194
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 732
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Thu Jul 23 13:54:13 2015
Last mount time: Tue Aug 4 04:35:06 2015
Last write time: Tue Aug 4 04:35:06 2015
Mount count: 3
Maximum mount count: -1
Last checked: Thu Jul 23 13:54:13 2015
Check interval: 0 (<none>)
Lifetime writes: 150 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup: inode blocks
Bug dans l'implémentation de la fonction ext4 dir_index que vous utilisez sur votre système de fichiers de destination.
Solution: recréez 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 de l'arborescence H sur un système de fichiers ext qui se rapporte bien à ext3 peut nécessiter une prudence similaire.
(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 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 a un "petit" problème: ext4 ne développe pas sa table de hachage lorsqu'il commence à se remplir. Au lieu de cela, il renvoie -ENOSPC ou "aucun espace laissé sur l'appareil".
Suggestions de choix meilleurs que 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, peut-être 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 aussi accessible avec d'autres API. Je ne sais pas si cela vaut la peine d'être utilisé sur un seul hôte, sans tirer parti de la réplication.
Un autre système de stockage d'objets est Swift d'OpenStack . Ses documents de conception le disent stocke chaque objet dans un fichier séparé, avec des métadonnées dans xattrs . Voici n article à ce sujet. Leur guide de déploiement indique qu'ils ont trouvé que XFS offrait les meilleures performances pour le stockage d'objets. Donc, même si la charge de travail n'est pas celle pour laquelle XFS est le meilleur, elle était apparemment meilleure que les concurrents lorsque RackSpace testait les choses. Peut-être Swift favorise XFS parce que XFS a une bonne/rapide prise en charge des attributs étendus. Il se peut que ext3/ext4 fonctionnerait correctement sur des disques uniques comme backend de stockage d'objets si des métadonnées supplémentaires n'étaient pas nécessaires (ou s'il a été conservé 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 complètement, donc vous ne le faites pas obtenir des écritures pleine bande, et RAID5 doit faire quelques lectures pour mettre à jour la bande de parité. Swift les documents parlent également d'utiliser 100 partitions par lecteur. Je suppose que c'est un Swift terme, et ne parle pas de faire 100 systèmes de fichiers XFS différents sur chaque disque SATA.
L'exécution d'un XFS distinct pour chaque disque est en fait une énorme différence . Au lieu d'une gigantesque carte d'inode libre, chaque disque aura un XFS séparé avec des listes libres distinctes. De plus, cela évite la pénalité RAID5 pour les petites écritures.
Si vous avez déjà construit votre logiciel 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 tout vos fichiers dans un seul répertoire. (Je n'ai pas vu Swift disent comment ils disposent leurs fichiers dans plusieurs répertoires, mais je suis certain qu'ils le font).)
Avec presque n'importe quel système de fichiers normal, il sera utile d'utiliser une structure comme
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
Probablement environ 10 000 entrées sont raisonnables, donc prendre 4 caractères bien répartis de vos noms d'objets et les utiliser comme répertoires est une solution facile. 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 d'énormes masses de petits fichiers. Il fait ce qu'il peut, mais il est plus optimisé pour le streaming d'écritures 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 vaut toujours mieux utiliser au moins un arbre à un niveau.)
Dave Chinner avait quelques commentaires sur les performances XFS avec un grand nombre d'inodes alloués , conduisant à des performances slow-ish touch. Trouver un inode libre à allouer commence à prendre plus de temps CPU, car le bitmap d'inode gratuit est fragmenté. Notez que ce n'est pas un problème de répertoire unique par rapport à plusieurs répertoires, mais plutôt un problème de nombreux inodes utilisés sur l'ensemble du système de fichiers. La division de vos fichiers en plusieurs répertoires permet de résoudre certains problèmes, comme celui qui s'est étouffé dans ext4 dans l'OP, mais pas le problème du disque entier de garder une trace de l'espace libre. Le système de fichiers séparé par disque de Swift aide à cela, par rapport à XFS géant sur RAID5.
Je ne sais pas si btrfs est bon dans ce domaine, mais je pense que oui. Je pense que Facebook emploie son développeur principal pour une raison. : P Quelques repères que j'ai vus, des trucs comme dégager une source du noyau Linux, montrent que btrfs marche bien.
Je sais que 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 cependant être intéressant d'expérimenter. Mais c'est de loin le choix le moins pérenne. J'ai également vu des rapports de dégradation des performances sur les anciens reiserFS, et il n'y a pas de bon outil de défragmentation. (Google filesystem millions of small files, et examinez certaines des réponses stackexchange existantes.)
Je manque probablement quelque chose, alors recommandation finale: posez des questions à ce sujet sur serverfault! Si je devais choisir quelque chose maintenant, je dirais donner BTRFS essayez, mais assurez-vous d'avoir des sauvegardes. (en particulier si vous utilisez la redondance de disques multiples intégrée à BTRFS, au lieu de l'exécuter sur RAID. Les avantages en termes de performances peuvent être importants, car les petits fichiers sont de mauvaises nouvelles pour RAID5, à moins qu'il ne s'agisse d'une charge de travail en lecture seule.)
Pour ce problème, 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% qui peut être récupéré en utilisant la commande ci-dessous
df -i /
Inodes du système de fichiers IUsed IFree IUse% Mounted on
/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 {} +