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 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 dedf -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

L'exécution de la commande suggérée ci-dessous btrfs fi balance start -dusage=5 /mnt/durablem'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 un 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 -dusagedé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_cacheremontage est dû à certains 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.)

Je multiplie les usageoptions pour libérer progressivement de l'espace pour des soldes de plus en plus grands.

#!/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 blocage (ou un 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 aura forcément ... 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. OU vous pouvez, 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é dans l'ensemble). 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