"Kein Platz mehr auf dem Gerät" -Fehler, obwohl auf btrfs viel Platz vorhanden ist

Fast überall bekomme ich Fehler in Protokollen, über die ich mich beschwere No space left on device

Gitlab-Protokolle:

==> /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)

Dovecot E-Mail-Protokolle:

Nov 29 20:28:32 aws-management dovecot: imap(email@www.sitename.com): Error: open(/home/vmail/emailuser/Maildir/dovecot-uidlist.lock) failed: No space left on device

Ausgabe von 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

Sieht so aus, als gäbe es auch viel Inode-Platz. Ausgabe vondf -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

Ausgabe von 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

Ausgabe von 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

Woran könnte das liegen? Ich verwende eine Basis-Linux-AMI ec2-Kernversion 4.4.5-15.26.amzn1.x86_64

Aktualisieren

Wenn btrfs fi balance start -dusage=5 /mnt/durableich den unten vorgeschlagenen Befehl ausführe, erhalte ich einen Fehler der folgenden Art:

ERROR: error during balancing '/mnt/durable' - No space left on device There may be more info in syslog - try dmesg | tail

Nach dem manuellen Löschen einer Reihe größerer Dateien mit insgesamt ~ 1 GB habe ich den Computer neu gestartet und erneut versucht, um sicherzustellen, dass ich sudo verwendet habe, und den Befehl ausgeführt. Ich habe dann meinen Rechner noch einmal hochgefahren und es scheint das Problem gelöst zu haben

Willkommen in der Welt von BTRFS. Es hat einige verlockende Eigenschaften, aber auch einige ärgerliche Probleme.

Zunächst einige Informationen zu Ihrem Setup. Es sieht so aus, als hätten Sie vier Laufwerke in einem BTRFS-RAID-10-Volume (alle Daten werden also zweimal auf verschiedenen Datenträgern gespeichert). Dieses BTRFS-Volume wird dann in Sub-Volumes an verschiedenen Mount-Punkten aufgeteilt. Die Sub-Volumes teilen sich einen Pool von Festplattenspeicher, haben jedoch separate Inode-Nummern und können an verschiedenen Stellen bereitgestellt werden.

BTRFS ordnet Speicherplatz in "Chunks" zu, ein Chunk wird einer bestimmten Klasse von Daten oder Metadaten zugeordnet. Was passieren kann (und wie es in Ihrem Fall aussieht) ist, dass der gesamte freie Speicherplatz Datenblöcken zugewiesen wird, die keinen Platz für Metadaten lassen

Es scheint auch (aus Gründen, die ich nicht vollständig verstehe), dass BTRFs keinen Metadatenbereich mehr haben, bevor der Indikator für den Anteil des verwendeten Metadatenbereichs 100% erreicht.

Dies scheint in Ihrem Fall der Fall zu sein. Es gibt viele freie Daten, aber keinen freien Speicherplatz, der nicht für Blöcke reserviert wurde, und nicht genügend freien Speicherplatz in den vorhandenen Metadatenblöcken.

Die Lösung besteht darin, eine "Neuverteilung" durchzuführen. Dadurch werden Daten verschoben, sodass einige Blöcke in den "globalen" freien Pool zurückgegeben werden können, wo sie als Metadatenblöcke neu zugeordnet werden können

btrfs fi balance start -dusage=5 /mnt/durable

Die Zahl nach -dusagelegt fest, wie aggressiv die Neuverteilung ist, dh wie nah die Blöcke an der Leerstelle sein müssen, um neu geschrieben zu werden. Wenn der Kontostand anzeigt, dass 0 Blöcke neu geschrieben wurden, versuchen Sie es erneut mit einem höheren Wert von -dusage.

Wenn der Abgleich fehlschlägt, würde ich versuchen, einen Neustart durchzuführen und / oder Speicherplatz freizugeben, indem ich Dateien entferne.

Da Sie btrfs mit einem RAID-Setup ausführen, versuchen Sie, einen Ausgleichsvorgang auszuführen.

btrfs balance start /var/opt/gitlab

Wenn dies den Fehler verursacht, dass nicht genügend Speicherplatz vorhanden ist, versuchen Sie es mit der folgenden Syntax erneut:

btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab 

Wiederholen Sie diesen Vorgang für jedes btrfs-Dateisystem, bei dem Speicherplatzfehler auftreten. Wenn Ihr Speicherplatzproblem darauf zurückzuführen ist, dass die Metadaten nicht auf die gespiegelten Datenträger verteilt werden, wird möglicherweise Speicherplatz für Sie frei.

Auf meinem System habe ich den folgenden Job in cron.monthly hinzugefügt.

Der clear_cacheRemount ist auf einige Korruptionsprobleme zurückzuführen, die btrfs mit den kostenlosen Karten hatte. (Ich denke, sie haben das Problem endlich gefunden, aber das Problem ist so ärgerlich, dass ich bereit bin, dafür zu zahlen, dass die Karten einmal im Monat neu erstellt werden.)

Ich erweitere die usageOptionen, um schrittweise Speicherplatz für immer größere Konten freizugeben.

#!/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

Wenn Sie den Punkt erreichen, an dem Sie aufgrund unzureichenden Speicherplatzes keine Neuverteilung durchführen können, empfiehlt es sich, für die Dauer der Neuverteilung vorübergehend ein anderes Blockgerät (oder Loopback-Gerät auf einer anderen Festplatte) zu Ihrem Volume hinzuzufügen entfernen Sie es.

Dies ist weniger ein Problem mit btrfs, als vielmehr etwas, das mit diesem System gemacht wurde. Dies scheint das Ergebnis eines unvollständigen Ausgleichs von einer "einzelnen" Zuweisungsrichtlinie zu einer "RAID 10" -Zuweisungsrichtlinie zu sein, was durch die große Anzahl von einzelnen zugewiesenen Blöcken belegt wird. Es hat wahrscheinlich als Single angefangen und dann wurde eine Konvertierung abgebrochen. Ein Pool mit solch inkonsistenter Allokation muss ... nun, Allokationsprobleme haben.

Bedenken Sie, dass Sie 61% Ihres Pools verbraucht haben. Ihre Zuweisungsrichtlinie lautet RAID10, sodass der Pool-Verbrauch vor Erreichen des vollen Werts maximal 50% betragen sollte, da alles Replikat 2 ist. Aus diesem Grund ist Ihre Konvertierung von Single zu RAID 10 fehlgeschlagen (und weiterhin). Ich kann nur raten, aber es wurde wahrscheinlich in der Mitte eines Ausgleichs zugeteilt. Auf Ihrem Gerät ist kein Platz mehr für die Wiederherstellung eines RAID 10-Ausgleichs mit den vorhandenen Festplatten vorhanden. Der einzige Grund, warum Sie 61% erreicht haben, ist, dass Ihre Festplatten inkonsistent zugewiesen sind, einige davon linear mit einfacher Zuordnung, und die meisten in RAID 10.

Sie können eine Neuverteilung auf eine einzelne Zuweisungsrichtlinie vornehmen, wenn Sie Speicherplatz gewinnen möchten, ohne viel von irgendetwas zu ändern. Sie können auch mehr Festplatten hinzufügen oder die Größe der Festplatten erhöhen. ODER Sie könnten, wie in diesem Fall, einfach eine Reihe von Dateien löschen, damit Ihr Pool tatsächlich auf RAID 10 aufgeteilt werden kann (da insgesamt weniger als 50% verbraucht würden). Stellen Sie sicher, dass Sie nach dem Löschen von Dateien eine Neuverteilung durchführen.

Erzwingen Sie insbesondere RAID 10 beim Neuausgleichen nach dem Löschen dieser Dateien, um sicherzustellen, dass Sie diese einzelnen zugewiesenen Blöcke wie folgt entfernen:

btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home