Cosa fa apparire vuoto un dataset ZFS dopo un montaggio riuscito?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Un dataset ZFS può risultare montato ma apparire vuoto quando i dati attesi si trovano in un dataset figlio, in un punto di montaggio nascosto o in una radice di importazione diversa.

Il flag di montaggio dimostra che un dataset è collegato a un percorso, ma non dimostra che il percorso sia quello previsto da un’applicazione o da un utente, che i dataset figli siano montati al suo interno o che un discendente crittografato sia stato sbloccato. Un dataset padre vuoto può essere perfettamente integro, mentre tutti i file reali si trovano nei dataset figli. Inizia confrontando le proprietà dei dataset, lo spazio referenziato, le tabelle dei mount e la vista della directory prima di copiare dati o modificare la struttura del pool.

Confronta lo spazio del dataset con la directory che hai aperto

Registra il nome del dataset e i valori di USED, REFER, AVAIL, MOUNTPOINT e MOUNTED. Quindi elenca la directory esatta mostrata all’utente o all’applicazione.

Se il dataset segnala una quantità di dati referenziati quasi nulla, i file potrebbero appartenere a un dataset figlio, a uno snapshot, a un clone o a un altro dataset con un nome simile. Il manuale ZFS di FreeBSD descrive i dataset come filesystem gestiti separatamente, quindi l’utilizzo a livello di pool e una directory aperta non rappresentano necessariamente lo stesso dataset.

Non dedurre una perdita di dati dal solo browser grafico dei file. Confronta la vista delle proprietà ZFS, la tabella dei mount del sistema operativo e una shell locale con privilegi di root, esterna a qualsiasi container o namespace applicativo limitato.

Verifica insieme mountpoint, mounted e canmount

Controlla se il mountpoint del dataset è esplicito o ereditato, se è effettivamente montato in quel percorso e se canmount è impostato su on, off o noauto.

La guida di Oracle sulle proprietà ZFS spiega che mountpoint e canmount determinano se un dataset viene montato automaticamente, solo quando richiesto oppure utilizzato esclusivamente per passare proprietà ai discendenti.

Un dataset può fornire proprietà ereditate ai propri figli pur rimanendo intenzionalmente non montato. Al contrario, un dataset che utilizza un mountpoint legacy può apparire corretto nelle proprietà ZFS, ma dipendere da una voce di montaggio separata del sistema che non è stata eseguita.

Esamina i mount dei dataset padre e figli

Elenca l’intero albero dei dataset sotto il pool e ordina l’elenco per mountpoint. Confronta il dataset padre con ogni figlio che dovrebbe contenere file utente, dati delle applicazioni, backup o contenuti multimediali.

Un padre vuoto è comune quando esiste solo per organizzare proprietà e mountpoint. Il namespace dei dataset ZFS di FreeBSD tratta ogni figlio come un dataset gestito separatamente, quindi pool/data può essere vuoto mentre pool/data/photos contiene i file effettivi.

Se il padre viene montato ma un figlio no, diagnostica il figlio separatamente. Controlla canmount, le chiavi di crittografia, i mountpoint in conflitto, le importazioni non riuscite e l’eventualità che un servizio sia stato avviato prima del completamento del mount del figlio.

-15% OFF

Verifica se il mount ha nascosto file già presenti nella directory

Prima che un dataset venga montato sopra una directory, in quella directory possono già esistere dei file. Una volta montato il dataset ZFS, i file sottostanti vengono nascosti dal percorso, anche se rimangono nel filesystem root.

Smonta il dataset solo durante una finestra di manutenzione controllata e controlla la directory sottostante dall’host. Il manuale dei mount di Linux afferma che i contenuti preesistenti del punto di montaggio diventano invisibili mentre il filesystem montato occupa quel percorso.

Può verificarsi anche il problema opposto: un mount ZFS previsto non riesce e lascia visibile agli utenti e ai container la directory sottostante vuota. In questo modo un dataset integro può sembrare vuoto, anche se semplicemente non è collegato al percorso che viene esposto.

Escludi una radice alternativa e il comportamento dei mount legacy

Controlla se il pool è stato importato con una radice alternativa, un’opzione di ripristino, un percorso di montaggio temporaneo o un nome di pool diverso. Un dataset può essere montato correttamente sotto un percorso di ripristino con prefisso anziché nella normale posizione di produzione.

L’importazione di un pool con una radice alternativa riscrive i percorsi di montaggio dei dataset in relazione a quella radice temporanea. La documentazione di riferimento di zpool import di Ubuntu specifica che -R imposta altroot, mentre -N può importare il pool senza montare i filesystem.

Esamina anche i dataset il cui mountpoint è impostato su legacy. In questa modalità ZFS non gestisce automaticamente il mount, quindi la configurazione dei mount del sistema operativo diventa la fonte di verità.

Controlla i figli crittografati e i namespace di montaggio dei container

Un dataset figlio crittografato può rimanere non disponibile dopo il montaggio del padre se la chiave non è stata caricata o se il mount del figlio non è riuscito. La directory del padre appare quindi vuota o incompleta anche se il pool è online.

Verifica lo stato della chiave e del mount per ogni discendente crittografato, quindi confronta il percorso dell’host con quello presentato al container. La documentazione LXD di Canonical spiega che i dispositivi disco dei container mappano le origini dell’host su percorsi separati dell’istanza, quindi un dataset figlio visibile sull’host può essere comunque assente da un mount più vecchio del container.

Se l’host vede i dati ma un container no, controlla l’origine del bind del container e la propagazione del mount. Un container creato prima del montaggio del figlio ZFS può continuare a visualizzare la directory sottostante vuota finché il servizio non viene ricreato o il mount non viene propagato correttamente.

Ripristina la visualizzazione corretta senza copiare il dataset

Correggi la proprietà o il percorso più piccolo per cui hai una causa certa: monta il figlio mancante, correggi un mountpoint ereditato, rimuovi una radice alternativa non intenzionale, ripara la voce di mount legacy, carica la chiave di crittografia oppure ricrea il container con l’origine bind corretta.

La checklist di ripristino del server domestico di ZimaSpace stabilisce una regola correlata: verifica il livello di archiviazione e lo stato dei mount prima di eseguire strumenti di riparazione o ripristinare i dati.

La diagnosi è completa quando il dataset previsto e i mount dei figli compaiono nei percorsi desiderati, lo spazio referenziato corrisponde ai file visibili, le applicazioni vedono lo stesso albero dell’host e la struttura rimane corretta dopo esportazione, importazione, riavvio del servizio e riavvio del sistema.

Supporto e consigli

Altro da leggere

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.