Waardoor lijkt een ZFS-dataset leeg nadat deze succesvol is gekoppeld?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een ZFS-dataset kan aangeven dat deze is aangekoppeld, maar toch leeg lijken wanneer de verwachte gegevens zich in een child-dataset, verborgen mountpoint of andere importroot bevinden.

De vlag voor aangekoppeld zijn bewijst dat één dataset aan één pad is gekoppeld; deze bewijst niet dat het pad het pad is dat een toepassing of gebruiker verwacht, dat child-datasets eronder zijn aangekoppeld of dat een versleutelde afstammeling is ontgrendeld. Een lege parent-dataset kan volledig gezond zijn terwijl alle echte bestanden in child-datasets staan. Begin met het vergelijken van dataset-eigenschappen, gerefereerde ruimte, mounttabellen en de directoryweergave voordat je gegevens kopieert of de poolstructuur wijzigt.

Vergelijk de ruimte van de dataset met de directory die je hebt geopend

Noteer de datasetnaam en de waarden voor USED, REFER, AVAIL, MOUNTPOINT en MOUNTED. Geef vervolgens de exacte directory weer die aan de gebruiker of toepassing wordt getoond.

Als de dataset vrijwel geen gerefereerde gegevens bevat, behoren de bestanden mogelijk tot een child-dataset, snapshot, clone of andere dataset met een vergelijkbare naam. Het FreeBSD ZFS-handboek beschrijft datasets als afzonderlijk beheerde bestandssystemen. Poolgebruik en één geopende directory vertegenwoordigen daarom niet noodzakelijk dezelfde dataset.

Leid niet alleen uit de grafische bestandsbrowser af dat er gegevens verloren zijn gegaan. Vergelijk de ZFS-eigenschappenweergave, de mounttabel van het besturingssysteem en een lokale root-shell die zich buiten elke container of beperkte applicatienaamruimte bevindt.

Controleer mountpoint, mounted en canmount samen

Controleer of het mountpoint van de dataset expliciet is ingesteld of wordt overgenomen, of de dataset daadwerkelijk op dat pad is aangekoppeld en of canmount is ingesteld op on, off of noauto.

De richtlijnen van Oracle voor ZFS-eigenschappen leggen uit dat mountpoint en canmount bepalen of een dataset automatisch, alleen op verzoek of helemaal niet wordt aangekoppeld en alleen dient om eigenschappen aan afstammelingen door te geven.

Een dataset kan overgenomen eigenschappen aan zijn child-datasets leveren en tegelijkertijd bewust niet zelf zijn aangekoppeld. Omgekeerd kan een dataset met een legacy-mountpoint er in de ZFS-eigenschappen correct uitzien, maar afhankelijk zijn van een afzonderlijke systeemvermelding voor het aankoppelen die niet is uitgevoerd.

Controleer mounts van parent- en child-datasets

Geef de volledige datasetboom onder de pool weer en sorteer deze op mountpoint. Vergelijk de parent-dataset met elke child-dataset die gebruikersbestanden, applicatiegegevens, back-ups of media zou moeten bevatten.

Een lege parent-dataset komt vaak voor wanneer deze alleen dient om eigenschappen en mountpoints te organiseren. De ZFS-datasetnaamruimte van FreeBSD behandelt elke child als een afzonderlijk beheerde dataset. Zo kan pool/data leeg zijn terwijl pool/data/photos de daadwerkelijke bestanden bevat.

Als de parent wel wordt aangekoppeld maar een child niet, diagnoseer de child afzonderlijk. Controleer canmount, versleutelingssleutels, conflicterende mountpoints, mislukte imports en of een service is gestart voordat het aankoppelen van de child was voltooid.

-15% OFF
Single board computer zimaboard2

Controleer of het mountpoint bestaande bestanden verbergt

Bestanden kunnen al in een gewone directory staan voordat een dataset daarbovenop wordt aangekoppeld. Zodra de ZFS-dataset is aangekoppeld, worden die onderliggende bestanden vanaf dat pad verborgen, ook al blijven ze op het rootbestandssysteem staan.

Koppel de dataset alleen af tijdens een gecontroleerd onderhoudsvenster en inspecteer de onderliggende directory vanaf de host. De Linux-handleiding voor mounten vermeldt dat bestaande inhoud van een mountpoint onzichtbaar wordt zolang het aangekoppelde bestandssysteem dat pad gebruikt.

Het omgekeerde probleem komt ook voor: een verwachte ZFS-mount mislukt, waardoor de lege onderliggende directory zichtbaar blijft voor gebruikers en containers. Daardoor kan een gezonde dataset leeg lijken, terwijl deze simpelweg niet is gekoppeld aan het pad dat wordt aangeboden.

Sluit een alternatieve root en legacy-mountgedrag uit

Controleer of de pool is geïmporteerd met een alternatieve root, hersteloptie, tijdelijk mountpad of andere poolnaam. Een dataset kan succesvol zijn aangekoppeld onder een geprefixt herstelpad in plaats van op de normale productielocatie.

Bij het importeren van een pool met een alternatieve root worden de mountlocaties van datasets herschreven ten opzichte van die tijdelijke root. De zpool-importreferentie van Ubuntu documenteert dat -R altroot instelt, terwijl -N een import zonder het aankoppelen van bestandssystemen kan uitvoeren.

Controleer ook datasets waarvan het mountpoint legacy is. In die modus beheert ZFS het aankoppelen niet automatisch en wordt de mountconfiguratie van het besturingssysteem de bron van waarheid.

Controleer versleutelde child-datasets en mountnaamruimten van containers

Een versleutelde child-dataset kan onbeschikbaar blijven nadat de parent is aangekoppeld als de sleutel niet is geladen of het aankoppelen van de child is mislukt. De parent-directory lijkt dan leeg of onvolledig, ook al is de pool online.

Controleer de sleutelstatus en mountstatus van elke versleutelde afstammeling en vergelijk vervolgens het hostpad met het pad dat aan de container wordt aangeboden. De LXD-documentatie van Canonical legt uit dat container-schijfapparaten hostbronnen koppelen aan afzonderlijke instancepaden. Daardoor kan een child-dataset die op de host zichtbaar is, nog ontbreken in een oudere containermount.

Als de host de gegevens wel ziet maar een container niet, controleer dan de bindbron van de container en de mountpropagatie. Een container die is aangemaakt voordat de ZFS-child werd aangekoppeld, kan de onderliggende lege directory blijven zien totdat de service opnieuw wordt aangemaakt of de mount correct wordt doorgegeven.

Herstel de juiste weergave zonder de dataset te kopiëren

Corrigeer de kleinst mogelijke bewezen eigenschap of het kleinst mogelijke pad: koppel de ontbrekende child aan, corrigeer een overgenomen mountpoint, verwijder een onbedoelde alternatieve root, herstel de legacy-mountvermelding, laad de versleutelingssleutel of maak de container opnieuw aan met de juiste bindbron.

De herstelchecklist voor homeservers van ZimaSpace bevat de bijbehorende regel: controleer de opslaglaag en mountstatus voordat je reparatietools uitvoert of gegevens terugzet.

De diagnose is voltooid wanneer de verwachte dataset en child-mounts op de bedoelde paden verschijnen, de gerefereerde ruimte overeenkomt met de zichtbare bestanden, toepassingen dezelfde boomstructuur zien als de host en de indeling behouden blijft na export, import, het herstarten van services en een reboot.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.