Impedindo que a conexão NFS interrompida congele o sistema do cliente

Temos um compartilhamento NFS 4, compartilhando um volume entre vários servidores (servidor NFS e clientes, todos Debian 8). Recentemente, tivemos alguns problemas nos quais as interrupções na rede congelavam os sistemas do cliente.

Opções Nossa NFS eram mínimas, apenas rw(e assim os padrões hard, fgetc).

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

(Aumentei os retrans para compensar parte do risco brando)

O procedimento que estou seguindo para testar é:

• Máquina de inicialização
• cd para /mnt/mountpoint
• Verifique a conexão NFS ok
• cd /
• matar rede ifdown eth0
• cd para /mnt/mountpoint
• ls

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

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

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

(PS: Eu também tentei montar com autofs, mas vi um comportamento semelhante)

Obrigado

intrdeve permitir o controle novamente quando você bate ^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 em uma operação é permanente. Portanto, a maioria das operações assume como padrão o bloqueio simples até que a operação seja concluída.

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

                  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 intrfunciona. Portanto, você deve poder acompanhar KILLo processo, mas isso pode não lhe dar muita utilidade.

Não consegui encontrar a discussão sobre por que a opção foi removida. Você pode matar -KILL seu processo?

Parte da minha resposta é opinião, baseada na experiência. Onde eu tiver fatos, tentarei (lembre-se de) vincular a eles.

1. O NFS 4 é considerado uma melhoria em relação às versões 2 e 3. No entanto, ainda não vi um forte caso de uso por precisar das melhorias. Talvez seja porque eu pretendo exportar sistemas de arquivos para clientes Windows com Samba e para clientes Unix / Linux com NFS.
2. Eu não recomendaria softem quase nenhuma circunstância. Permite que os dados sejam descartados por erro . Em vez disso, eu sugiro hard,intr.
3. Como você ressalta, intrnão é válido para o NFS 4, mas parece que essa é uma alteração do kernel em vez de uma alteração no NFS.
4. O NFS Automounter ( autofs) funciona bem para meus casos de uso com as versões 2 e 3 do NFS e consegue ajudar a proteger meus sistemas clientes de falhas do servidor montando os sistemas de arquivos NFS apenas quando necessário.

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 downgrade.