Warum bleibt ein Btrfs-Balance-Vorgang nach dem Verschieben von Daten auf ein größeres Laufwerk hängen?

Ein Btrfs-Balance kann nach dem Hinzufügen eines größeren Laufwerks scheinbar hängen, weil für die Relokation weiterhin freier Speicher als Chunk-Arbeitsbereich benötigt wird und möglicherweise das gesamte Dateisystem verarbeitet wird.

Das Ersetzen eines Laufwerks oder das Kopieren von Daten auf ein größeres Gerät sorgt nicht automatisch dafür, dass alle Btrfs-Blockgruppen kompakt, gleichmäßig verteilt oder für eine Relokation geeignet sind. Ein Balance arbeitet auf Blockgruppenebene, erstellt einen temporären Arbeitsbereich, aktualisiert Metadaten und kann durch das langsamste Gerät, Snapshots, Prüfsummen oder einen anderen exklusiven Vorgang begrenzt werden. Zunächst muss zwischen einer tatsächlich feststeckenden Relokation und einem langsamen vollständigen Balance unterschieden werden, das weiterhin Fortschritte macht.

Bestätigen, ob das Balance läuft, pausiert oder wartet

Prüfen Sie den Balance-Status, die Anzahl der verarbeiteten Chunks, das Kernel-Log, den Festplattendurchsatz und die Latenz pro Gerät. Halten Sie fest, ob der Befehl im Vordergrund oder Hintergrund läuft, pausiert oder abgebrochen wurde oder nach einem Neustart automatisch fortgesetzt wird.

Ein Balance kann lange damit beschäftigt sein, eine stark belegte Blockgruppe zu verschieben, bevor sich der sichtbare Zähler ändert. Die Btrfs-Anleitung von ArchWiki zeigt, wie Sie den Balance-Status und die Dateisystemauslastung verwenden, um fortgesetzte Arbeit von einem bereits beendeten Befehl zu unterscheiden.

Wenn weder I/O noch eine Statusänderung festzustellen ist und das Kernel-Log einen Fehler meldet, behandeln Sie den Vorgang als beendet und nicht als langsam. Sichern Sie die erste Fehlermeldung, bevor Sie das Balance mit anderen Filtern neu starten.

Überprüfen, ob das größere Gerät und das Dateisystem vergrößert wurden

Vergleichen Sie die physische Gerätegröße, die Partitionsgröße, die Btrfs-Gerätegröße und die Dateisystemzuweisung. Ein größeres Ersatzlaufwerk kann weiterhin durch die alte Partitionsgrenze oder die alte Btrfs-Gerätegröße eingeschränkt sein.

Bestätigen Sie jede Ebene in der richtigen Reihenfolge: Hardwarekapazität, Partitionstabelle, Blockgerät, Btrfs-Gerätebestand und Dateisystemzuweisung. SUSE dokumentiert, dass zuerst das Gerät vergrößert werden muss, bevor das Dateisystem erweitert wird. Ein Balance kann daher keine Kapazität nutzen, die Btrfs noch nicht erkennt.

Der ZimaSpace-Artikel über nicht wachsende Kapazität nach dem Ersetzen eines Laufwerks bietet die entsprechende Überprüfung der einzelnen Ebenen, bevor die Relokation als Ursache vermutet wird.

Freie Bytes von freiem Chunk-Arbeitsbereich unterscheiden

Vergleichen Sie die gesamte Gerätegröße mit dem bereits Btrfs-Blockgruppen zugewiesenen Speicher. Ein Dateisystem kann den Benutzern zwar freie Bytes anzeigen, aber dennoch keinen vollständig nicht zugewiesenen Bereich besitzen, der groß genug ist, um die für die Relokation erforderliche temporäre Blockgruppe zu erstellen.

Die Btrfs-Dokumentation zum Balance erklärt, dass für die Relokation ein vollständig ungenutzter Blockgruppen-Arbeitsbereich erforderlich ist. Dieser unterscheidet sich vom gewöhnlichen freien Speicher auf Dateiebene und kann während eines Balance zu ENOSPC führen.

Wenn der Arbeitsbereich knapp ist, geben Sie zunächst vollständig ungenutzte Blockgruppen mit einem engen Auslastungsfilter frei, statt ein weiteres vollständiges Balance zu starten. Löschen Sie Snapshots nicht wahllos, bevor ihr Beitrag zur Chunk-Zuweisung gemessen wurde.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Prüfen, ob ein vollständiges Balance ohne Filter gestartet wurde

Überprüfen Sie den ursprünglichen Befehl. Ein Balance ohne Daten- oder Metadatenfilter versucht, das gesamte Dateisystem zu verschieben, selbst wenn eigentlich nur gering belegte Chunks kompaktiert oder Zuweisungen von einem bestimmten Gerät weg verschoben werden sollen.

Ein vollständiges Balance kann viele Stunden oder Tage dauern, weil jede ausgewählte Blockgruppe neu geschrieben wird. Das Linux-Handbuch zu btrfs-balance warnt, dass ein Lauf ohne Filter Daten und Metadaten über das gesamte Dateisystem verschiebt und alle Blockzeiger aktualisiert.

Verwenden Sie die Statusausgabe und den bisherigen Verlauf der Shell, um die aktiven Filter zu ermitteln. Brechen Sie den Vorgang nicht wiederholt ab und starten Sie ihn nicht ständig neu, da unterbrochene Balances teilweise gefüllte Blockgruppen hinterlassen können, die weiterhin Arbeitsbereich belegen.

Langsame Geräte, Fehler und konkurrierende exklusive Vorgänge prüfen

Überprüfen Sie SMART-Daten, Übertragungsfehler, Link-Resets, USB- oder SATA-Timeouts sowie die Latenz pro Gerät. Die Geschwindigkeit eines Balance wird durch das Lesen aus alten Speicherorten, das Schreiben an neue Speicherorte, die Prüfsummenvalidierung und Metadatenaktualisierungen begrenzt.

Prüfen Sie außerdem Scrub, das Hinzufügen oder Entfernen von Geräten, die Dateisystemvergrößerung, das Löschen von Snapshots, Send- oder Receive-Vorgänge sowie andere Speicheraktivitäten. Der Btrfs-Administrationsleitfaden von Red Hat beschreibt Geräteänderungen und Balance als Relokationsvorgänge. Überlappende Wartungsarbeiten können daher auch dann eine starke Konkurrenzsituation verursachen, wenn kein Laufwerk ausgefallen ist.

Wenn ein Gerät wiederholt Resets oder eine extrem hohe Latenz aufweist, pausieren Sie das Balance und diagnostizieren Sie diesen Pfad, bevor Sie weitere Relokationen erzwingen. Die Fortsetzung mit einem instabilen Gerät kann aus einem Leistungsproblem ein Wiederherstellungsproblem machen.

Für einen kontrollierten Neustart enge Filter und Begrenzungen verwenden

Nachdem Sie den aktuellen Zustand gesichert haben, beginnen Sie mit dem Filter mit dem geringsten Risiko, der auf leere oder nur leicht belegte Blockgruppen abzielt. Begrenzen Sie die Anzahl der Chunks pro Lauf, damit jedes Ergebnis beobachtet werden kann, bevor der Umfang erhöht wird.

Erhöhen Sie den Auslastungsschwellenwert schrittweise und behandeln Sie Daten und Metadaten getrennt. Eine Metadatenrelokation kann zahlreiche zusätzliche Aktualisierungen erzeugen und muss nicht aggressiv kompaktiert werden, nur weil die durchschnittliche Auslastung niedrig erscheint.

Pausieren Sie den Vorgang, setzen Sie ihn fort oder brechen Sie ihn über die unterstützten Balance-Steuerungen ab, statt den Prozess zu beenden. Bestätigen Sie, dass die aktuelle Blockgruppe abgeschlossen wird und der gespeicherte Balance-Zustand mit der nächsten Aktion übereinstimmt.

Verteilung und Kapazität nach dem Balance überprüfen

Vergleichen Sie die Zuweisung pro Gerät, Daten- und Metadatenprofile, den nicht zugewiesenen Arbeitsbereich, die Dateisystemauslastung und die Anzahl der verschobenen Chunks vor und nach dem kontrollierten Balance.

Ein erfolgreiches Ergebnis bedeutet nicht zwangsläufig eine vollkommen gleichmäßige Byte-Auslastung auf jedem Laufwerk. Die Linux-Kernelübersicht führt die integrierte Unterstützung mehrerer Geräte und die Online-Größenänderung auf. Der abschließende Test sollte sich daher auf gültige Profile, nutzbare Zuweisungen, fehlerfreie Geräte und ausreichend Arbeitsbereich für zukünftige Schreibvorgänge konzentrieren.

Das Problem ist behoben, wenn das Balance abgeschlossen wird oder den vorgesehenen gefilterten Umfang erreicht, das größere Gerät neue Zuweisungen erhält, freier Chunk-Arbeitsbereich wiederhergestellt ist und normale Schreibvorgänge, Snapshots, Scrub und Neustarts funktionieren, ohne dass das Balance unerwartet neu gestartet wird.