reiniciar o cliente NFS sem reiniciar

Estou trabalhando no meu servidor, do qual exporto um diretório usando o NFS. É claro que, durante uma semana ou mais das reinicializações do servidor, esqueci várias vezes umounto sistema de arquivos de exportação na minha estação de trabalho (que é montada /etc/fstabna inicialização). Entre eu era capaz de umountapós o fato e remount (estou não usando autofs):

umount -fl /data0
mount /data0

Mas isso não funciona mais.

Não consigo montar o diretório exportado do servidor em um diretório diferente (montagem trava), mas posso nfs montar esse diretório exportado em uma máquina virtual em execução na minha estação de trabalho.

O que eu tentei é remover ( rmmod) o módulo nfse nfsv3(que não funcionaria Resource temporarily unavailable:). lsoftrava. mountnão mostra nada montado via nfs. Provavelmente, tudo isso é resultado do uso de 'umount -l' várias vezes, mas as duas primeiras vezes funcionaram sem problemas.

Eu reiniciei o servidor nesse meio tempo, depois de não conseguir montar sem que isso fizesse diferença. Eu também usei service nfs-kernel-server restart. Eu suspeito que tudo voltaria ao normal se eu reiniciar a estação de trabalho do cliente.

Existe uma maneira de recuperar isso e reinicializar o lado do cliente nfs na minha estação de trabalho sem uma reinicialização?
Se eu não conseguir corrigir isso sem reiniciar, isso não ocorrerá novamente se eu começar a usar autofs?

lsof -b trava com as últimas linhas:

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.

nas linhas anteriores a isso, não há /data0.

A entrada em /etc/fstab:

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

Como o @PaperMonkey sugeriu nos comentários, você pode se ferrar porque usou as opções de montagem padrão, que incluem tentar novamente para sempre.

intrcostumava ser uma maneira de facilitar a interrupção de coisas que estavam presas na E / S em uma montagem NFS quebrada, mas agora é uma operação não operacional. SIGKILLainda pode interromper os processos presos no NFS, pelo menos assim nfs(5). Veja essa página de manual para opções de montagem.

Use em softvez do padrão hardse desejar que o NFS não tente novamente para sempre.

Eu também recomendo usar o montador automático. Faça links simbólicos para / net / host / foo / bar em algum lugar, se desejar.

Muitas vezes, é mais fácil apenas reiniciar, mas acho que, em teoria, você deve kill -9(ie kill -KILL) qualquer processo que esteja preso no NFS. ENTÃO umount -f pode funcionar. Apenas tome cuidado para não deixar que o preenchimento de guias fique com mais processos presos na montagem do NFS.

Abaixo está uma lista de comandos a serem executados para corrigir esse problema em uma distribuição baseada em RPM.

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

Depois disso:

umount -f /share

O uso autofsajudará a evitar esse problema no futuro. O maior benefício autofsé que ele não tenta montar o diretório até tentar usá-lo, o que significa que você evita pontos de montagem quebrados e que ele não tenta montar indefinidamente, é possível definir um período de tempo limite para desmontagem (o que normalmente é curto). Não tenho certeza se o automount tenta novamente durante esse período de pré-impressão, mas de qualquer forma, normalmente, defino o tempo limite do automount para apenas alguns segundos.

Para resolver o problema sem ter de reiniciar você pode ser capaz de conviver com umount -a(desmontar todos mencionados em / etc / fstab) mount -a(montar tudo em / etc / fstab), mas eu tenho a menos que o diretório que você perdeu contém o diretório home que você' é melhor salvar o trabalho em outro lugar e apenas reiniciar.

Use os resultados do comando lsof para localizar os processos no cliente que mantêm referências ao sistema de arquivos obsoletos e eliminar esses processos.

umount -f / data0

verifique se você pode executar ping no servidor e remontar a unidade. Reinicie os processos desejados.

Clusters

Observe que, se você executar uma configuração do servidor de cluster, obterá um identificador de arquivo nfs obsoleto toda vez que o servidor fizer failover. Para evitar isso, você deve exportar seus sistemas de arquivos usando a opção fsid. O número do fsid deve ser o mesmo para cada sistema de arquivos respectivo nos dois servidores. Cabe a você garantir a replicação dos arquivos. Veja o trecho da página de manual abaixo:

fsid = num | root | uuid O NFS precisa ser capaz de identificar cada sistema de arquivos que exporta. Normalmente, ele usará um UUID para o sistema de arquivos (se o sistema de arquivos tiver algo assim) ou o número do dispositivo que contém o sistema de arquivos (se o sistema de arquivos estiver armazenado no dispositivo). Como nem todos os sistemas de arquivos estão armazenados em dispositivos e nem todos os sistemas de arquivos têm UUIDs, às vezes é necessário dizer explicitamente ao NFS como identificar um sistema de arquivos. Isso é feito com a opção fsid =.

Para o NFSv4, existe um sistema de arquivos distinto que é a raiz de todo o sistema de arquivos exportado. Isso é especificado com fsid = root ou fsid = 0, o que significa exatamente a mesma coisa.

Outros sistemas de arquivos podem ser identificados com um número inteiro pequeno ou um UUID que deve conter 32 dígitos hexadecimais e pontuação arbitrária.

Os kernels do Linux versão 2.6.20 e anterior não entendem a configuração UUID, portanto, um número inteiro pequeno deve ser usado se uma opção fsid precisar ser definida para esses kernels. A definição de um número pequeno e de um UUID é suportada para que a mesma configuração possa ser feita para funcionar tanto em kernels antigos quanto em novos.