Erreur "Il n'y a plus d'espace sur l'appareil" malgré le manque d'espace, sur btrfs
Presque partout, je reçois des échecs dans les journaux se plaignant de No space left on device
Journaux Gitlab:
==> /var/log/gitlab/nginx/current <==
2016-11-29_20:26:51.61394 2016/11/29 20:26:51 [emerg] 4871#0: open() "/var/opt/gitlab/nginx/nginx.pid" failed (28: No space left on device)
Journaux de messagerie Dovecot:
Nov 29 20:28:32 aws-management dovecot: imap([email protected]): Error: open(/home/vmail/emailuser/Maildir/dovecot-uidlist.lock) failed: No space left on device
Sortie de df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 ext4 7.8G 3.9G 3.8G 51% /
devtmpfs devtmpfs 1.9G 28K 1.9G 1% /dev
tmpfs tmpfs 1.9G 12K 1.9G 1% /dev/shm
/dev/xvdh btrfs 20G 13G 7.9G 61% /mnt/durable
/dev/xvdh btrfs 20G 13G 7.9G 61% /home
/dev/xvdh btrfs 20G 13G 7.9G 61% /opt/gitlab
/dev/xvdh btrfs 20G 13G 7.9G 61% /var/opt/gitlab
/dev/xvdh btrfs 20G 13G 7.9G 61% /var/cache/salt
On dirait qu'il y a aussi beaucoup d'espace inode. Sortie de df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 524288 105031 419257 21% /
devtmpfs 475308 439 474869 1% /dev
tmpfs 480258 4 480254 1% /dev/shm
/dev/xvdh 0 0 0 - /mnt/durable
/dev/xvdh 0 0 0 - /home
/dev/xvdh 0 0 0 - /opt/gitlab
/dev/xvdh 0 0 0 - /var/opt/gitlab
/dev/xvdh 0 0 0 - /var/cache/salt
Sortie de btrfs fi show
Label: none uuid: 6546c241-e57e-4a3f-bf43-fa933a3b29f9
Total devices 4 FS bytes used 11.86GiB
devid 1 size 10.00GiB used 10.00GiB path /dev/xvdh
devid 2 size 10.00GiB used 9.98GiB path /dev/xvdi
devid 3 size 10.00GiB used 9.98GiB path /dev/xvdj
devid 4 size 10.00GiB used 9.98GiB path /dev/xvdk
Sortie de btrfs fi df /mnt/durable
Data, RAID10: total=17.95GiB, used=10.12GiB
Data, single: total=8.00MiB, used=0.00
System, RAID10: total=16.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID10: total=2.00GiB, used=1.74GiB
Metadata, single: total=8.00MiB, used=0.00
unknown, single: total=272.00MiB, used=8.39MiB
Quelle pourrait en être la cause? J'utilise une base Linux AMI ec2 kernal version 4.4.5-15.26.amzn1.x86_64
Mise à jour
Exécution de la commande suggérée ci-dessous btrfs fi balance start -dusage=5 /mnt/durable m'a renvoyé une erreur de ce qui suit:
ERROR: error during balancing '/mnt/durable' - No space left on device There may be more info in syslog - try dmesg | tail
Après avoir supprimé manuellement un tas de fichiers plus volumineux totalisant environ 1 Go, j'ai redémarré la machine et réessayé, en m'assurant que j'utilisais Sudo et la commande exécutée. J'ai ensuite redémarré ma machine une fois de plus pour faire bonne mesure et cela semble avoir résolu le problème
Bienvenue dans le monde de BTRFS. Il a des fonctionnalités alléchantes mais aussi des problèmes exaspérants.
Tout d'abord, quelques informations sur votre configuration, il semble que vous ayez quatre disques dans un volume "raid 10" BTRFS (donc toutes les données sont stockées deux fois sur des disques différents). Ce volume BTRFS est ensuite découpé en sous-volumes sur différents points de montage. Les sous-volumes partagent un pool d'espace disque mais ont des numéros d'inode distincts et peuvent être montés à différents endroits.
BTRFS alloue l'espace en "morceaux", un morceau est alloué à une classe spécifique de données ou de métadonnées. Ce qui peut arriver (et il semble que ce soit arrivé dans votre cas) est que tout l'espace libre est alloué aux blocs de données ne laissant aucune place aux métadonnées
Il semble également que (pour des raisons que je ne comprends pas bien), les BTRF "manquent" d'espace de métadonnées avant que l'indicateur de la proportion d'espace de métadonnées utilisé n'atteigne 100%.
Cela semble être le cas dans votre cas, il y a beaucoup d'espace libre de données mais pas d'espace libre qui n'a pas été alloué aux morceaux et l'espace libre insuffisant dans les morceaux de métadonnées existants.
Le correctif consiste à exécuter un "rééquilibrage". Cela déplacera les données afin que certains morceaux puissent être retournés au pool gratuit "global" où ils peuvent être réaffectés en tant que morceaux de métadonnées
btrfs fi balance start -dusage=5 /mnt/durable
Le nombre après -dusage définit à quel point le rééquilibrage est agressif, c'est-à-dire à quel point les blocs doivent être vides pour être réécrits. Si la balance indique qu'elle a réécrit 0 bloc, essayez à nouveau avec une valeur plus élevée de -dusage.
Si l'équilibre échoue, j'essaierais de redémarrer et/ou de libérer de l'espace en supprimant des fichiers.
Puisque vous exécutez btrfs avec une configuration RAID, essayez d'exécuter une opération d'équilibrage.
btrfs balance start /var/opt/gitlab
Si cela donne une erreur sur le manque d'espace, essayez à nouveau avec cette syntaxe:
btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab
Répétez cette opération pour chaque système de fichiers btrfs où vous voyez des erreurs d'espace. Si votre problème d'espace est dû au fait que les métadonnées ne sont pas distribuées sur les disques en miroir, cela peut libérer de l'espace pour vous.
Sur mon système, j'ai ajouté le travail suivant dans cron.monthly.
Le clear_cache le remontage est dû à des problèmes de corruption rencontrés par btrfs avec les cartes gratuites. (Je pense qu'ils ont finalement trouvé le problème, mais le problème est tellement ennuyeux, je suis prêt à payer pour reconstruire les cartes une fois par mois.)
J'augmente les options usage pour libérer progressivement de l'espace pour des soldes de plus en plus importants.
#!/bin/sh
for mountpoint in `mount -t btrfs | awk '{print $3}' | sort -u`
do
echo --------------------------
echo Balancing $mountpoint :
echo --------------------------
echo remount with clear_cache...
mount -oremount,clear_cache $mountpoint
echo Before:
/usr/sbin/btrfs fi show $mountpoint
/usr/sbin/btrfs fi df $mountpoint
for size in 0 1 5 10 20 30 40 50 60 70 80 90
do
time /usr/sbin/btrfs balance start -v -musage=$size $mountpoint 2>&1
time /usr/sbin/btrfs balance start -v -dusage=$size $mountpoint 2>&1
done
echo After:
/usr/sbin/btrfs fi show $mountpoint
/usr/sbin/btrfs fi df $mountpoint
done
Si vous arrivez au point où vous ne pouvez pas rééquilibrer parce que votre espace est insuffisant, la recommandation est d'ajouter temporairement un autre périphérique de bloc (ou périphérique de bouclage sur un autre disque) d'une certaine sorte à votre volume pendant la durée du rééquilibrage, puis le retirer.
Ce n'est pas tellement un problème avec btrfs, mais c'est quelque chose qui a été fait pour ce système. Cela ressemble au résultat d'un rééquilibrage incomplet d'une politique d'allocation "unique" à une politique d'allocation "raid 10", comme en témoigne le grand nombre de blocs alloués individuellement. Cela a probablement commencé en tant que single, puis une conversion a été interrompue. Un pool avec une telle allocation incohérente est lié à avoir ... eh bien, des problèmes d'allocation.
Considérez que vous avez consommé 61% de votre pool. Votre politique d'allocation est RAID10, ce qui devrait entraîner une consommation maximale de 50% du pool avant d'atteindre le niveau maximum, car tout est répliqué 2. C'est pourquoi votre conversion de single à RAID 10 a échoué (et continue de l'être). Je ne peux que deviner, mais il a probablement été alloué au milieu d'un rééquilibrage. Il n'y a plus d'espace sur votre appareil pour rééquilibrer vers un RAID 10 avec les disques dont vous disposez. La seule raison pour laquelle vous avez atteint 61% est que vos disques sont alloués par incohérence, certains linéairement avec une allocation unique, et la plupart en RAID 10.
Vous pouvez rééquilibrer vers une politique d'allocation unique si vous souhaitez gagner de l'espace sans changer grand-chose. Vous pouvez également ajouter plus de disques ou augmenter la taille des disques. OR vous pourriez, comme vous l'avez fait dans ce cas, simplement supprimer un tas de fichiers afin que votre pool puisse réellement s'équilibrer en RAID 10 (car il serait moins de 50% consommé globalement). Assurez-vous de rééquilibrer après la suppression des fichiers, ou vous aurez toujours cette politique d'allocation saccadée.
Plus précisément, appliquez RAID 10 lors du rééquilibrage après la suppression de ces fichiers pour vous assurer de vous débarrasser de ces blocs alloués, comme suit:
btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home