Vad gör att en ZFS-datamängd verkar tom efter att den har monterats utan problem?
En ZFS-dataset kan rapporteras som monterad men ändå se tom ut när de förväntade uppgifterna finns i en underordnad dataset, döljs av en monteringspunkt eller använder en annan importrot.
Flaggan för monterad visar att en dataset är ansluten till en sökväg; den bevisar inte att sökvägen är den som ett program eller en användare förväntar sig, att underordnade dataset är monterade under den eller att en krypterad underordnad dataset har låsts upp. En tom överordnad dataset kan vara helt felfri medan alla verkliga filer finns i underordnade dataset. Börja med att jämföra datasetegenskaper, refererat utrymme, monteringstabeller och katalogvyn innan du kopierar data eller ändrar poolens struktur.
Jämför datasetens utrymme med katalogen du öppnade
Notera datasetens namn samt värdena för USED, REFER, AVAIL, MOUNTPOINT och MOUNTED. Lista sedan den exakta katalog som visas för användaren eller programmet.
Om datasetens rapporterade mängd refererade data är nästan noll kan filerna tillhöra en underordnad dataset, ögonblicksbild, klon eller en annan dataset med ett liknande namn. FreeBSD:s ZFS-handbok beskriver dataset som separat hanterade filsystem, så användningen på poolnivå och en öppnad katalog representerar inte nödvändigtvis samma dataset.
Dra inte slutsatsen att data har gått förlorade enbart utifrån den grafiska filhanteraren. Jämför ZFS-egenskaperna, operativsystemets monteringstabell och ett lokalt root-skal på värddatorn som befinner sig utanför containrar eller begränsade programnamnrymder.
Kontrollera mountpoint, mounted och canmount tillsammans
Kontrollera om datasetens monteringspunkt är explicit angiven eller ärvd, om den faktiskt är monterad på den sökvägen och om canmount är on, off eller noauto.
Oracles vägledning om ZFS-egenskaper förklarar att mountpoint och canmount avgör om en dataset monteras automatiskt, endast monteras när det begärs eller enbart används för att föra vidare egenskaper till underordnade dataset.
En dataset kan tillhandahålla ärvda egenskaper till sina underordnade dataset samtidigt som den avsiktligt förblir omonterad. Omvänt kan en dataset med en äldre monteringspunkt se korrekt ut i ZFS-egenskaperna men vara beroende av en separat monteringspost i systemet som inte kördes.
Inspektera monteringar av överordnade och underordnade dataset
Lista hela datasethierarkin under poolen och sortera den efter monteringspunkt. Jämför den överordnade dataset med varje underordnad dataset som ska innehålla användarfiler, programdata, säkerhetskopior eller medier.
En tom överordnad dataset är vanlig när den endast finns för att organisera egenskaper och monteringspunkter. FreeBSD:s ZFS-datasetnamnrymd behandlar varje underordnad dataset som en egen hanterad dataset, så pool/data kan vara tom medan pool/data/photos innehåller de faktiska filerna.
Om den överordnade dataset monteras men en underordnad dataset inte gör det, ska den underordnade dataset felsökas separat. Kontrollera canmount, krypteringsnycklar, motstridiga monteringspunkter, misslyckade importer och om en tjänst startade innan monteringen av den underordnade dataset var klar.
Kontrollera om monteringen dolde filer som redan fanns i katalogen
Filer kan finnas i den vanliga katalogen innan en dataset monteras ovanpå den. När ZFS-dataseten väl är monterad döljs de underliggande filerna från sökvägen, även om de fortfarande finns i rotfilsystemet.
Avmontera dataset endast under ett kontrollerat underhållsfönster och inspektera den underliggande katalogen från värddatorn. Linux handbok för montering anger att befintligt innehåll i monteringspunkten blir osynligt medan det monterade filsystemet använder sökvägen.
Det omvända felet kan också inträffa: en förväntad ZFS-montering misslyckas, så att den tomma underliggande katalogen visas för användare och containrar. Då kan en felfri dataset se tom ut, trots att den helt enkelt inte är ansluten till den sökväg som används.
Uteslut alternativ rot och äldre monteringsbeteende
Kontrollera om poolen importerades med en alternativ rot, ett återställningsalternativ, en tillfällig monteringssökväg eller ett annat poolnamn. En dataset kan vara korrekt monterad under en prefixed återställningssökväg i stället för på sin normala produktionsplats.
Om en pool importeras med en alternativ rot skrivs datasetens monteringsplatser om i förhållande till den tillfälliga roten. Ubuntus referens för zpool import dokumenterar att -R anger altroot, medan -N kan importera utan att montera filsystem.
Inspektera även dataset vars monteringspunkt är legacy. I det läget hanterar ZFS inte monteringen automatiskt, så operativsystemets monteringskonfiguration blir den källa som gäller.
Kontrollera krypterade underordnade dataset och monteringsnamnrymder för containrar
En krypterad underordnad dataset kan förbli otillgänglig efter att den överordnade dataset har monterats om nyckeln inte har lästs in eller monteringen av den underordnade dataset misslyckades. Den överordnade katalogen ser då tom eller ofullständig ut trots att poolen är online.
Kontrollera nyckelstatus och monteringsstatus för alla krypterade underordnade dataset och jämför sedan värddatorns sökväg med sökvägen som visas i containern. Canonicals LXD-dokumentation förklarar att diskresurser i containrar mappar källor på värddatorn till separata instanssökvägar, så en underordnad dataset som är synlig på värddatorn ändå kan saknas i en äldre containermontering.
Om värddatorn ser data men en container inte gör det, inspektera containerns bind-källa och monteringsspridning. En container som skapades innan den underordnade ZFS-dataseten monterades kan fortsätta att se den underliggande tomma katalogen tills tjänsten återskapas eller monteringen sprids korrekt.
Återställ rätt vy utan att kopiera dataset
Åtgärda den minsta bekräftade egenskapen eller sökvägen: montera den saknade underordnade dataset, korrigera en ärvd monteringspunkt, ta bort en oavsiktlig alternativ rot, reparera den äldre monteringsposten, läs in krypteringsnyckeln eller återskapa containern med rätt bind-källa.
ZimaSpaces checklista för återställning av hemmaservrar ger en närliggande regel: verifiera lagringslagret och monteringsstatusen innan du kör reparationsverktyg eller återställer data.
Diagnosen är klar när den förväntade dataset och dess underordnade monteringar visas på avsedda sökvägar, refererat utrymme överensstämmer med synliga filer, programmen ser samma träd som värddatorn och layouten består efter export, import, omstart av tjänster och omstart av systemet.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
