Impedindo que a conexão NFS quebrada congelasse o sistema do cliente

Question

Nós temos um compartilhamento NFS 4, compartilhando um volume entre um número de servidores (servidor NFS e clientes todos Debian 8). Recentemente, tivemos alguns problemas em que as interrupções de rede congelariam os sistemas do cliente.

Nossas opções de NFS eram mínimas, apenas rw (e, portanto, os padrões hard , fg , etc).

Agora estou experimentando essas opções, mas não estou obtendo o comportamento esperado:   rw,soft,bg,retrans=6,timeo=150

(Eu aumentei os retrans para compensar parte do risco suave)

O procedimento que estou seguindo para testar é:

• Máquina de inicialização
• cd to /mnt/mountpoint
• Verifique se a conexão NFS está ok
• cd /
• mate a rede ifdown eth0
• cd to /mnt/mountpoint
• ls

Neste ponto, a linha de comando congela, e eu não posso interrompê-la. Depois de algum tempo a mensagem 'nfs: server [servername] não está respondendo, expirou', o que parece repetir uma vez um minuto (indefinidamente).

O que eu gostaria / esperava que acontecesse para a operação falhar e retornar o controle.

Por favor, alguém poderia me dizer onde estou errado com essas configurações?

(PS: eu também tentei montar com o autofs, mas vi um comportamento similar)

Obrigado

    

Answer 1

intr deve permitir que você obtenha controle novamente quando atingir ^C , mas geralmente não imediatamente.

   intr           If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the
                  file  operation  and cause it to return EINTR to the calling program.  The default is to not allow file
                  operations to be interrupted.

Como você diz, as expectativas são o problema aqui. Os problemas de rede podem ser temporários, mas a falha de uma operação é permanente. Assim, a maioria das operações padrão simplesmente para bloquear até que a operação seja concluída.

Esta é a resposta padrão, mas olhando para uma página de manual atual eu vejo isto:

                  The  intr / nointr mount option is deprecated after ker-
                  nel 2.6.25.  Only SIGKILL can interrupt  a  pending  NFS
                  operation on these kernels, and if specified, this mount
                  option is ignored  to  provide  backwards  compatibility
                  with older kernels.

Portanto, não me parece ser um problema do NFS3 / NFS4, mas uma decisão sobre como o intr funciona. Então você deve ser capaz de KILL do processo, mas isso pode não lhe dar muita utilidade.

Não consegui encontrar a discussão sobre o motivo da remoção da opção. Você pode matar o seu processo?

    

Answer 2

Algumas das minhas respostas são opiniões baseadas na experiência. Onde eu tenho fatos eu vou (tentar lembrar de) link para eles.

1. O NFS 4 é considerado uma melhoria nas versões 2 e 3. No entanto, ainda não visto um caso de uso strong para precisar das melhorias. Talvez seja porque pretendo exportar sistemas de arquivos para clientes Windows com Samba e para clientes Unix / Linux com NFS.
2. Eu não recomendaria soft em quase nenhuma circunstância. Ele permite que os dados sejam descartados no erro . Em vez disso, sugiro hard,intr .
3. Como você aponta, intr não é válido para o NFS 4, mas parece que esta é uma mudança no kernel em vez de um NFS.
4. O NSS Automounter ( autofs ) funciona bem para meus casos de uso com as versões 2 e 3 do NFS, e ajuda a proteger meus sistemas clientes da falha do servidor montando os sistemas de arquivos NFS somente quando forem necessários.

Minha sugestão para você seria considerar a mudança do NFS 4 para o NFS 3 e ver se isso ajuda no seu caso de uso específico. Não pense nisso como um rebaixamento.