reinizializzare il client NFS senza riavvio

Ho lavorato sul mio server, dal quale esporto una directory usando NFS. Naturalmente durante la settimana circa di riavvii del server, ho dimenticato più volte umountil filesystem di esportazione nella mia workstation (che viene montato /etc/fstaball'avvio). In mezzo ho potuto umountdopo il fatto e rimontare (sto non usando autofs):

umount -fl /data0
mount /data0

Ma questo non funziona più.

Non riesco a montare la directory esportata dal server su una directory diversa (mount hang), ma posso nfs montare quella directory esportata su una macchina virtuale in esecuzione sulla mia workstation.

Quello che ho provato è rimuovere ( rmmod) il modulo nfse nfsv3(che non funzionerebbe:) Resource temporarily unavailable. lsofsi blocca. mountnon mostra nulla montato tramite nfs. Probabilmente questo è il risultato dell'uso di 'umount -l' più volte, ma le prime due volte hanno funzionato senza problemi.

Nel frattempo ho riavviato il server, dopo non essere stato in grado di montare senza fare alcuna differenza. Ho anche usato service nfs-kernel-server restart. Sospetto che tutto tornerebbe alla normalità se riavvio la workstation client.

C'è un modo per recuperare da questo e reinizializzare il lato client nfs sulla mia workstation senza riavviare?
Se non riesco a risolvere questo problema senza riavviare, ciò non si ripresenterebbe se inizio a utilizzare autofs?

lsof -b si blocca con le ultime righe:

lsof: avoiding readlink(/run/user/1001/gvfs): -b was specified.
lsof: avoiding stat(/run/user/1001/gvfs): -b was specified.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1001/gvfs
      Output information may be incomplete.

nelle righe precedenti, non esiste /data0.

La voce in /etc/fstab:

192.168.0.2:/data0 /data0  nfs  defaults,auto,nolock,user 0 2

Come suggerito da @PaperMonkey nei commenti, potresti essere fregato perché hai utilizzato le opzioni di montaggio predefinite, che includono un nuovo tentativo per sempre.

intrera un modo per semplificare l'interruzione di cose bloccate su I / O su un mount NFS rotto, ma ora è una no-op. SIGKILLpuò ancora interrompere i processi bloccati su NFS, almeno così nfs(5)afferma. Vedi quella pagina man per le opzioni di mount.

Utilizzare al softposto di quello predefinito hardse si desidera che NFS non riprovi per sempre.

Consiglio anche di usare l'automounter. Crea collegamenti simbolici a / net / host / foo / bar da qualche parte, se vuoi.

Spesso è più semplice riavviare, ma penso che in teoria dovresti essere in grado kill -9(cioè kill -KILL) di qualsiasi processo bloccato su NFS. POI umount -f potrebbe funzionare. Fai solo attenzione a non lasciare che il completamento con le schede ottenga più processi bloccati sul mount NFS.

Di seguito è riportato un elenco di comandi da eseguire per risolvere questo problema in una distribuzione basata su RPM.

service rpcbind stop
service nfslock stop
rm -rf /var/lib/nfs/statd/sm/*
rm -rf /var/lib/nfs/statd/sm.bak/*

Dopo di che:

umount -f /share

L'utilizzo autofsaiuterà a evitare questo problema in futuro. Il vantaggio principale autofsè che non tenta di montare la directory fino a quando non si tenta di utilizzarla, ciò significa che si evitano punti di montaggio interrotti e che non si tenta di montare indefinitamente, è possibile impostare un periodo di timeout per lo smontaggio (che è normalmente corto). Non sono sicuro se l'automount riprova durante questo periodo di pretimout, ma in entrambi i casi normalmente imposto il timeout di automount su solo pochi secondi.

Per risolvere il problema senza riavviare si potrebbe essere in grado di cavarsela con umount -a(smontare tutti elencati in / etc / fstab) mount -a(montare il tutto in / etc / fstab), ma ho meno che la directory che hai perso contiene la home directory' è meglio salvare il lavoro altrove e riavviare.

Utilizzare i risultati del comando lsof per trovare i processi sul client che contengono riferimenti al file system non aggiornato e terminare tali processi.

umount -f / data0

assicurarsi di poter eseguire il ping del server, quindi reinstallare l'unità. Riavvia tutti i processi desiderati.

Cluster

Nota, se si esegue un'installazione del server cluster si otterrà un handle di file NFS non aggiornato ogni volta che il server deve eseguire il failover. Per evitare che tu debba esportare i tuoi file system usando l'opzione fsid. Il numero per fsid dovrebbe essere lo stesso per ciascun rispettivo file system sui due server. Sta a te garantire che si verifichi la replica dei file. Vedi lo snippet dalla pagina man in basso:

fsid = num | root | uuid NFS deve essere in grado di identificare ogni filesystem che esporta. Normalmente userà un UUID per il filesystem (se il filesystem ha una cosa del genere) o il numero del dispositivo del dispositivo che tiene il filesystem (se il filesystem è memorizzato sul dispositivo). Poiché non tutti i filesystem sono archiviati su dispositivi e non tutti i filesystem hanno UUID, a volte è necessario dire esplicitamente a NFS come identificare un filesystem. Questo viene fatto con l'opzione fsid =.

Per NFSv4, esiste un filesystem distinto che è la radice di tutti i filesystem esportati. Questo è specificato con fsid = root o fsid = 0 entrambi significano esattamente la stessa cosa.

Altri filesystem possono essere identificati con un numero intero piccolo o un UUID che dovrebbe contenere 32 cifre esadecimali e punteggiatura arbitraria.

I kernel Linux versione 2.6.20 e precedenti non comprendono l'impostazione UUID, pertanto è necessario utilizzare un numero intero piccolo se è necessario impostare un'opzione fsid per tali kernel. È supportata l'impostazione sia di un numero piccolo che di un UUID, in modo che la stessa configurazione possa essere fatta funzionare su kernel vecchi e nuovi.