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 protected]): 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/durable
ich 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
Antworten:
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
Die Zahl nach
-dusage
legt 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.
quelle
ERROR: error during balancing '/mnt/durable' - No space left on device
noch nach dem Löschen von fast 1 GB von der Festplattedmesg | tail
in meinem Beitrag hinzugefügt, nachdem nach dem Neustart ein neuer Fehler angezeigt wurde.Da Sie btrfs mit einem RAID-Setup ausführen, versuchen Sie, einen Ausgleichsvorgang auszuführen.
Wenn dies den Fehler verursacht, dass nicht genügend Speicherplatz vorhanden ist, versuchen Sie es mit der folgenden Syntax erneut:
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.
quelle
Refusing to explicitly operate on system chunks. Pass --force if you really want to do that.
Ist das in Ordnung?-susage=0
Option.Auf meinem System habe ich den folgenden Job in cron.monthly hinzugefügt.
Der
clear_cache
Remount 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
usage
Optionen, um schrittweise Speicherplatz für immer größere Konten freizugeben.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.
quelle
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
quelle