Warum bleibt ein Btrfs-Snapshot ausgelastet, nachdem jeder App-Container beendet wurde?

Ein gestoppter Container kann einen Btrfs-Snapshot als belegt hinterlassen, wenn ein anderer Prozess, Mount-Namespace, Bind-Mount, Send-Auftrag oder verschachteltes Subvolume weiterhin darauf verweist.

Beim Stoppen eines Anwendungcontainers wird dessen Hauptprozess beendet. Das beweist jedoch nicht, dass jeder zugehörige Mount, Hilfsprozess, Laufzeit-Shim, Shell-Sitzung, Backup-Auftrag oder Namespace den Snapshot-Pfad freigegeben hat. Btrfs kann das Löschen außerdem ablehnen, wenn das Ziel gemountet ist, an einem Sendevorgang beteiligt ist, als Standard-Subvolume konfiguriert wurde oder verschachtelte Subvolumes enthält. Ermitteln Sie die genaue Referenz, bevor Sie einen Unmount erzwingen oder Containerdaten löschen.

Das genaue Btrfs-Objekt und den Fehler bestätigen

Notieren Sie den vollständigen Snapshot-Pfad, die Subvolume-ID, die übergeordnete ID, den Nur-Lese-Status, die UUID, die empfangene UUID und den genauen Löschfehler. Bestätigen Sie, dass es sich bei dem Pfad um ein Btrfs-Subvolume und nicht um ein gewöhnliches Verzeichnis innerhalb eines solchen handelt.

Die Referenz zu Btrfs-Subvolumes erklärt, dass Snapshots Subvolumes sind, und dokumentiert Bedingungen, die das Löschen verhindern, darunter der Status als Standard-Subvolume und ein aktiver Sendevorgang.

Wenn der Fehler nicht EBUSY lautet, verfolgen Sie die tatsächliche Ursache. Probleme mit Berechtigungen, Nur-Lese-Mounts, Standard-Subvolumes und verschachtelten Subvolumes erfordern andere Prüfungen als eine aktive Mount-Referenz.

Container-Stopp und Container-Entfernung getrennt betrachten

Listen Sie Container in den Zuständen laufend, gestoppt, beendet und wird entfernt auf. Notieren Sie die Container-IDs, die den Snapshot über Bind-Mounts, benannte Volumes oder einen Btrfs-Speichertreiber verwendet haben.

Die CLI-Referenz von Docker zeigt, dass docker stop ein Signal an den Hauptprozess sendet; dadurch werden weder die Containerdefinition noch Laufzeitmetadaten oder alle speicherbezogenen Beziehungen auf dem Host entfernt.

Löschen Sie den Snapshot nicht allein deshalb, weil die Anwendungsoberfläche anzeigt, dass der Stack gestoppt wurde. Prüfen Sie, ob noch eine Neustartrichtlinie, ein Health-Check-Hilfsprozess, eine Exec-Shell, ein Sidecar oder ein Container-Laufzeitprozess vorhanden ist.

Mounts in jedem relevanten Namespace prüfen

Vergleichen Sie die Mount-Tabelle des Hosts mit den Mount-Namespaces der Container-Laufzeit, gestoppter Container-Hilfsprozesse, Backup-Agenten und aller langlebigen Shells, die den Container betreten haben.

Das Linux-Handbuch erklärt, dass Mount-Namespaces Mount-Listen isolieren. Daher kann ein Pfad auf dem Host als nicht gemountet erscheinen, während er im Namespace eines anderen Prozesses weiterhin gemountet ist.

Verwenden Sie prozessspezifische Mount-Informationen, statt nur die aktuelle Shell zu prüfen. Ein Lazy-Unmount auf dem Host kann das Symptom verbergen, ohne den Namespace freizugeben, der die Referenz weiterhin hält.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Nach Container-Mounts suchen, die in einem anderen Namespace bestehen bleiben

Ermitteln Sie die Prozess-ID der Container-Laufzeit, des Shims, des Überwachungsagenten oder des Hilfsprozesses, der den Namespace möglicherweise weiterhin hält. Untersuchen Sie dessen Mount-Baum und den Quellpfad, der dem Btrfs-Snapshot entspricht.

Red Hat dokumentiert einen bestätigten Fall, in dem ein Mount in einem anderen Namespace Fehler wegen eines belegten Geräts oder einer belegten Ressource bei der Bereinigung verursacht. Das entspricht der Situation, in der der Host scheinbar frei ist, der Snapshot aber weiterhin referenziert wird.

Beenden Sie nur den nachweislich veralteten Hilfsprozess oder starten Sie die relevante Laufzeit während eines Wartungsfensters neu. Das Beenden nicht beteiligter Namespace-Besitzer kann andere Container und Mounts beeinträchtigen.

fuser und Prüfungen offener Handles unter Berücksichtigung der Namespace-Grenzen verwenden

Prüfen Sie offene Dateien, aktuelle Arbeitsverzeichnisse, eingebundene Dateien und Benutzer von Mounts unter dem Snapshot-Pfad. Führen Sie die Werkzeuge mit ausreichenden Berechtigungen aus und vergleichen Sie deren Prozessliste mit den Laufzeitprozessen.

Das fuser-Handbuch von Debian warnt, dass Blockgeräte, die von Prozessen in einem anderen Mount-Namespace gemountet wurden, möglicherweise nicht erkannt werden. Ein leeres Ergebnis beweist daher nicht, dass der Snapshot ungenutzt ist.

Prüfen Sie außerdem Shell-Sitzungen, deren aktuelles Verzeichnis innerhalb des Snapshots liegt, Dateiinhaltsindizierungsdienste, Virenscanner, Backup-Leseprozesse und Anwendungen, die Protokolldateien fortlaufend auslesen. Schließen Sie jeweils einen bestätigten Benutzer und wiederholen Sie die schreibgeschützte Statusprüfung.

Gemountete, standardmäßige, verschachtelte und sendende Subvolumes ausschließen

Listen Sie alle Mounts auf, die zur Subvolume-ID des Snapshots aufgelöst werden, prüfen Sie das Standard-Subvolume des Dateisystems, führen Sie alle verschachtelten untergeordneten Subvolumes auf und untersuchen Sie aktive Btrfs-Sendevorgänge.

ArchWiki weist darauf hin, dass ein gemountetes Subvolume nicht gelöscht werden sollte. Daher sind die Prüfung der Mount-Zuordnung und der verschachtelten Struktur vor dem Entfernen erforderlich.

Das Stoppen von Anwendungcontainern beendet keinen unabhängigen Btrfs-Sendevorgang, keine Snapshot-Replikation und keinen Backup-Prozess. Warten Sie, bis der Sendevorgang abgeschlossen ist, oder beenden Sie ihn ordnungsgemäß. Prüfen Sie anschließend den Status des Snapshots erneut.

Die nachgewiesene Referenz freigeben und sicher löschen

Hängen Sie den Snapshot in dem Namespace aus, der ihn besitzt, entfernen oder starten Sie das veraltete Container-Laufzeitobjekt gegebenenfalls neu, verlassen Sie Arbeitsverzeichnisse, beenden Sie die bestätigte Sendeaufgabe und löschen Sie verschachtelte Subvolumes in der richtigen Abhängigkeitsreihenfolge.

Der ZimaSpace-Artikel zum Erstellen von Snapshots für NAS-Anwendungsdaten liefert den ergänzenden Kontext, um zu bestimmen, welche persistenten Pfade und Anwendungszustände ein Container-Snapshot tatsächlich abdeckt.

Das Problem ist behoben, wenn kein Namespace und kein Prozess mehr auf das Subvolume verweist, der korrekte Snapshot, der nicht als Standard-Subvolume festgelegt ist, über den unterstützten Btrfs-Befehl gelöscht wird, die Hintergrundbereinigung abgeschlossen ist und der Anwendungsstack mit seinen vorgesehenen aktiven Datenpfaden neu gestartet wird.