Come risolvere gli handle di file NFS obsoleti dopo aver rinominato un dataset

Eva Wong

IceWhale author

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.

How to Resolve Stale NFS File Handles After Renaming a Dataset - Zima Store Online

I handle NFS obsoleti dopo aver rinominato un dataset indicano solitamente che il client conserva ancora riferimenti a oggetti o identità di esportazione modificati sul server.

Il recupero più sicuro consiste nel verificare se è obsoleto solo un client o se è cambiata l’identità dell’esportazione, arrestare le applicazioni che utilizzano attivamente il mount, verificare che il dataset rinominato sia esportato dal percorso previsto e quindi rimontare i client in un ordine controllato. Non riavviare tutte le macchine né ricreare il dataset finché non sai se l’handle obsoleto riguarda un solo mount client memorizzato nella cache o tutti i client che raggiungono l’esportazione rinominata.

Conferma che l’errore sia iniziato con la ridenominazione del dataset

Annota il vecchio nome e punto di mount del dataset, il nuovo nome e punto di mount, il percorso esportato e la prima operazione del client che ha restituito ESTALE. Confronta un client interessato con un client che ha montato la condivisione solo dopo la ridenominazione.

Un recente articolo sulla risoluzione dei problemi NFS spiega che un handle obsoleto indica che l’handle è cambiato, non semplicemente che il percorso di rete non è raggiungibile.

Se il mount di un client appena configurato funziona mentre quello di un client precedente non funziona, probabilmente l’esportazione rinominata è raggiungibile e il problema immediato riguarda lo stato memorizzato nella cache del vecchio client. Se anche i nuovi mount non funzionano, concentra l’indagine sull’esportazione del server e sull’identità del dataset.

Verifica che l’esportazione punti ora al dataset previsto

Controlla l’elenco attivo delle esportazioni del server e la tabella dei filesystem montati dopo la ridenominazione. Un percorso può continuare a esistere, ma ora risolvere in un dataset diverso, in un punto di mount vuoto o in una directory appartenente al filesystem errato.

OneUptime segnala che le modifiche alle esportazioni possono invalidare gli handle quando oggetti, esportazioni, identificativi del filesystem o dati ripristinati cambiano mentre esiste ancora un riferimento del client.

Correggi la destinazione dell’esportazione prima di intervenire sui client. Un remount verso il percorso errato sul server può sembrare risolvere ESTALE, puntando però silenziosamente le applicazioni a un albero di directory diverso.

Arresta i processi che utilizzano ancora il vecchio mount

Usa gli strumenti del client per mount e processi per individuare shell, server multimediali, processi di backup, container o database che hanno ancora aperto il vecchio mount NFS. Arresta il servizio interessato più piccolo prima di forzare lo smontaggio.

Una guida mirata al recupero su Linux consiglia di individuare i processi prima di rimontare, così da evitare che un passaggio di recupero lasci un processo in una visualizzazione del filesystem parzialmente scollegata.

Se un solo container utilizza il percorso obsoleto, arresta prima quel container. Se il mount è condiviso da molti servizi, pianifica una breve finestra di manutenzione invece di ricorrere subito agli smontaggi lazy su uno stack applicativo attivo.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Rimonta il client dopo aver stabilizzato il percorso del server

Una volta verificata l’esportazione del server e arrestati i servizi dipendenti, smonta e rimonta la condivisione NFS su un client di prova. Usa lo stesso indirizzo del server, percorso di esportazione, versione NFS e opzioni di mount che resteranno in produzione.

Un caso di migrazione NFS mostra che i client devono eseguire un nuovo mount dopo lo spostamento dello storage, anche quando permessi e dati copiati sono altrimenti corretti.

Verifica l’elenco delle directory, una lettura, una scrittura reversibile e il percorso effettivo dell’applicazione prima di rimontare tutti gli altri client. Se lo stesso client diventa nuovamente obsoleto subito, torna a esaminare l’identità del server invece di ripetere il remount.

Verifica se la ridenominazione ha modificato l’identità dell’handle di file

Gli handle di file NFS non sono normali stringhe di percorso. Codificano un’identità definita dal server che può includere informazioni relative al filesystem e agli inode; perciò sostituire, ripristinare o spostare il filesystem sottostante può avere conseguenze anche quando il percorso esportato visibile sembra simile.

Un’analisi approfondita degli handle di file mostra che gli handle di file associano l’identità del server, invece di funzionare come segnalibri per un percorso testuale.

Se la ridenominazione faceva in realtà parte della distruzione e ricreazione, della ricezione, della clonazione o del ripristino di un dataset, documenta questo cambiamento più ampio di identità. La soluzione corretta potrebbe essere un remount coordinato di tutti i client, invece di tentare di preservare indefinitamente i vecchi handle.

Verifica che ogni client utilizzi la nuova esportazione dopo il riavvio

Dopo che il primo client ha superato i test, rimonta gli altri client uno alla volta, riavvia i servizi dipendenti e verifica che le rispettive unità di mount configurate o i percorsi bind dei container facciano riferimento all’esportazione prevista. Poi riavvia un client non critico per verificare la persistenza.

Un articolo sulla risoluzione dei problemi di storage spiega che i mount obsoleti persistono oltre le applicazioni finché i processi che li utilizzano e lo stato del mount non vengono effettivamente aggiornati.

La riparazione è completa quando i client nuovi e quelli riavviati montano il dataset rinominato senza errori ESTALE e le applicazioni leggono i file previsti. La guida ZimaSpace correlata sui percorsi di mount stabili per i server domestici riguarda il caso adiacente in cui la ridenominazione dei dataset modifica anche i percorsi bind locali o delle applicazioni.

Domande frequenti

Un handle di file NFS obsoleto può indicare che il disco sta cedendo?

Non di per sé. ESTALE significa che l’handle memorizzato nella cache del client non identifica più l’oggetto sul server che il client si aspetta. Controlla separatamente lo stato dello storage se il server segnala anche errori di I/O o del filesystem.

Il riavvio del servizio NFS risolve sempre il problema?

No. Se l’esportazione ora punta a un’identità di dataset diversa, i vecchi handle del client restano errati. Verifica prima l’esportazione, quindi aggiorna deliberatamente i mount dei client.

È necessario riavviare tutti i client dopo aver rinominato un dataset?

Di solito no. Quando l’esportazione del server è corretta, è sufficiente arrestare i servizi interessati ed eseguire il remount. Riavvia un client solo se non riesce a rilasciare correttamente il mount obsoleto o come verifica finale della persistenza.