Was verursacht, dass ein ZFS-Dataset nach erfolgreichem Einhängen leer erscheint?

Ein ZFS-Dataset kann als eingehängt angezeigt werden und dennoch leer wirken, wenn sich die erwarteten Daten in einem untergeordneten Dataset, hinter einem verborgenen Einhängepunkt oder unter einem anderen Import-Stamm befinden.

Das Kennzeichen „eingehängt“ bestätigt, dass ein Dataset einem Pfad zugeordnet ist. Es bestätigt jedoch nicht, dass dieser Pfad dem von einer Anwendung oder einem Benutzer erwarteten Pfad entspricht, dass darunterliegende Datasets dort eingehängt wurden oder dass ein verschlüsselter Nachkomme entsperrt ist. Ein leeres übergeordnetes Dataset kann vollständig intakt sein, während sich alle tatsächlichen Dateien in untergeordneten Datasets befinden. Vergleichen Sie zunächst die Dataset-Eigenschaften, den referenzierten Speicherplatz, die Einhängetabellen und die Verzeichnisansicht, bevor Sie Daten kopieren oder die Pool-Struktur ändern.

Vergleichen Sie den Dataset-Speicherplatz mit dem geöffneten Verzeichnis

Notieren Sie den Dataset-Namen sowie die Werte für USED, REFER, AVAIL, MOUNTPOINT und MOUNTED. Listen Sie anschließend das genaue Verzeichnis auf, das dem Benutzer oder der Anwendung angezeigt wird.

Wenn das Dataset kaum referenzierte Daten meldet, gehören die Dateien möglicherweise zu einem untergeordneten Dataset, Snapshot, Klon oder einem anderen Dataset mit einem ähnlichen Namen. Das FreeBSD-ZFS-Handbuch beschreibt Datasets als separat verwaltete Dateisysteme. Daher stellen die Pool-Auslastung und ein geöffnetes Verzeichnis nicht zwangsläufig dasselbe Dataset dar.

Leiten Sie aus dem grafischen Dateibrowser allein keinen Datenverlust ab. Vergleichen Sie die ZFS-Eigenschaftsansicht, die Einhängetabelle des Betriebssystems und eine lokale Root-Shell auf dem Host, die sich außerhalb jedes Containers oder eingeschränkten Anwendungs-Namensraums befindet.

Prüfen Sie mountpoint, mounted und canmount gemeinsam

Prüfen Sie, ob der Einhängepunkt des Datasets explizit festgelegt oder geerbt ist, ob es tatsächlich unter diesem Pfad eingehängt ist und ob canmount auf on, off oder noauto gesetzt ist.

Die ZFS-Dokumentation von Oracle erklärt, dass mountpoint und canmount bestimmen, ob ein Dataset automatisch, nur auf Anfrage oder gar nicht eingehängt wird und lediglich Eigenschaften an Nachkommen weitergibt.

Ein Dataset kann geerbte Eigenschaften an seine untergeordneten Datasets weitergeben, während es selbst absichtlich nicht eingehängt ist. Umgekehrt kann ein Dataset mit einem Legacy-Einhängepunkt in den ZFS-Eigenschaften korrekt aussehen, aber von einem separaten System-Eintrag abhängen, der nicht ausgeführt wurde.

Prüfen Sie die Einhängungen übergeordneter und untergeordneter Datasets

Listen Sie den vollständigen Dataset-Baum unterhalb des Pools auf und sortieren Sie ihn nach Einhängepunkt. Vergleichen Sie das übergeordnete Dataset mit jedem untergeordneten Dataset, das Benutzerdaten, App-Daten, Backups oder Medien enthalten sollte.

Ein leeres übergeordnetes Dataset ist häufig, wenn es lediglich zur Organisation von Eigenschaften und Einhängepunkten dient. Der FreeBSD-ZFS-Dataset-Namensraum behandelt jedes untergeordnete Dataset als eigenes verwaltetes Dataset. Daher kann pool/data leer sein, während pool/data/photos die tatsächlichen Dateien enthält.

Wenn das übergeordnete Dataset eingehängt ist, ein untergeordnetes jedoch nicht, untersuchen Sie das untergeordnete Dataset unabhängig. Prüfen Sie canmount, Verschlüsselungsschlüssel, kollidierende Einhängepunkte, fehlgeschlagene Importe und ob ein Dienst gestartet wurde, bevor das untergeordnete Dataset vollständig eingehängt war.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Prüfen Sie, ob durch die Einhängung bereits vorhandene Dateien im Verzeichnis verborgen wurden

Dateien können bereits im normalen Verzeichnis vorhanden sein, bevor ein Dataset darüber eingehängt wird. Sobald das ZFS-Dataset eingehängt ist, werden die darunterliegenden Dateien in diesem Pfad verborgen, obwohl sie weiterhin im Root-Dateisystem vorhanden sind.

Hängen Sie das Dataset nur während eines kontrollierten Wartungsfensters aus und prüfen Sie das darunterliegende Verzeichnis auf dem Host. Das Linux-Handbuch zu mount erklärt, dass bereits vorhandene Inhalte des Einhängepunkts unsichtbar werden, solange das eingehängte Dateisystem diesen Pfad belegt.

Auch der umgekehrte Fehler tritt auf: Eine erwartete ZFS-Einhängung schlägt fehl, sodass das leere darunterliegende Verzeichnis für Benutzer und Container sichtbar bleibt. Dadurch kann ein intaktes Dataset leer wirken, obwohl es lediglich nicht an den bereitgestellten Pfad angebunden ist.

Schließen Sie einen alternativen Root und Legacy-Einhängeverhalten aus

Prüfen Sie, ob der Pool mit einem alternativen Root, einer Wiederherstellungsoption, einem temporären Einhängepfad oder einem anderen Pool-Namen importiert wurde. Ein Dataset kann erfolgreich unter einem vorangestellten Wiederherstellungspfad eingehängt sein, anstatt an seinem normalen Produktionsort.

Beim Import eines Pools mit einem alternativen Root werden die Einhängeorte der Datasets relativ zu diesem temporären Root angepasst. Die Referenz zu zpool import von Ubuntu dokumentiert, dass -R den Wert altroot setzt, während -N den Import ohne Einhängen der Dateisysteme ermöglicht.

Prüfen Sie außerdem Datasets, deren Einhängepunkt auf legacy gesetzt ist. In diesem Modus verwaltet ZFS die Einhängung nicht automatisch, sodass die Einhängekonfiguration des Betriebssystems maßgeblich ist.

Prüfen Sie verschlüsselte untergeordnete Datasets und Container-Einhängenamensräume

Ein verschlüsseltes untergeordnetes Dataset kann nach dem Einhängen seines übergeordneten Datasets weiterhin nicht verfügbar sein, wenn der Schlüssel nicht geladen wurde oder die Einhängung des untergeordneten Datasets fehlgeschlagen ist. Das übergeordnete Verzeichnis wirkt dann leer oder unvollständig, obwohl der Pool online ist.

Prüfen Sie den Schlüsselstatus und den Einhängestatus jedes verschlüsselten Nachkommen und vergleichen Sie anschließend den Host-Pfad mit dem im Container bereitgestellten Pfad. Die LXD-Dokumentation von Canonical erklärt, dass Container-Datenträgergeräte Host-Quellen auf separate Instanzpfade abbilden. Daher kann ein auf dem Host sichtbares untergeordnetes Dataset in einem älteren Container-Einhängen weiterhin fehlen.

Wenn der Host die Daten sieht, ein Container jedoch nicht, prüfen Sie die Bind-Quelle des Containers und die Mount-Propagation. Ein Container, der erstellt wurde, bevor das untergeordnete ZFS-Dataset eingehängt wurde, kann weiterhin das darunterliegende leere Verzeichnis sehen, bis der Dienst neu erstellt oder die Einhängung korrekt weitergegeben wird.

Stellen Sie die korrekte Ansicht wieder her, ohne das Dataset zu kopieren

Beheben Sie nur die kleinste nachgewiesene Ursache: Hängen Sie das fehlende untergeordnete Dataset ein, korrigieren Sie einen geerbten Einhängepunkt, entfernen Sie einen unbeabsichtigten alternativen Root, reparieren Sie den Legacy-Eintrag, laden Sie den Verschlüsselungsschlüssel oder erstellen Sie den Container mit der korrekten Bind-Quelle neu.

Die Checkliste zur Wiederherstellung eines Heimservers von ZimaSpace enthält die dazugehörige Grundregel: Prüfen Sie Speicherebene und Einhängezustand, bevor Sie Reparaturwerkzeuge ausführen oder Daten wiederherstellen.

Die Diagnose ist abgeschlossen, wenn das erwartete Dataset und die untergeordneten Einhängungen unter den vorgesehenen Pfaden erscheinen, der referenzierte Speicherplatz mit den sichtbaren Dateien übereinstimmt, Anwendungen denselben Verzeichnisbaum wie der Host sehen und das Layout Export, Import, Dienstneustart und Neustart übersteht.