Evitar que una conexión NFS interrumpida congele el sistema del cliente

Tenemos un recurso compartido NFS 4, que comparte un volumen entre varios servidores (servidor NFS y todos los clientes Debian 8). Recientemente hemos tenido algunos problemas donde las interrupciones de la red congelarían los sistemas del cliente.

Nuestro opciones NFS fueron mínimas, simplemente rw(y por lo tanto los valores por defecto hard, fgetc).

Ahora estoy experimentando con estas opciones, pero no obtengo el comportamiento que esperaba: rw,soft,bg,retrans=6,timeo=150

(He aumentado las retransmisiones para compensar parte del riesgo blando)

El procedimiento que estoy siguiendo para probar es:

• Máquina de arranque
• cd a /mnt/mountpoint
• Verifique que la conexión NFS esté bien
• cd /
• matar a la red ifdown eth0
• cd a /mnt/mountpoint
• ls

En este punto, la línea de comando se congela y no puedo interrumpirla. Después de un tiempo, el mensaje 'nfs: server [servername] no responde, expiró', que parece repetirse una vez por minuto (indefinidamente).

Lo que me gustaría / esperaría que suceda para que la operación falle y devuelva el control.

¿Podría alguien decirme dónde me estoy equivocando con esta configuración?

(PD: también intenté montar con autofs, pero vi un comportamiento similar)

Gracias

intrdebería permitirle recuperar el control cuando golpea ^C, pero generalmente no de inmediato.

   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 dices, las expectativas son el problema aquí. Los problemas de red pueden ser temporales, pero el fallo de una operación es permanente. Por lo tanto, la mayoría de las operaciones se configuran simplemente como bloqueo hasta que se completa la operación.

Esta es la respuesta estándar, pero al mirar una página de manual actual veo esto:

                  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.

Por lo tanto, no me parece un problema de NFS3 / NFS4, sino una decisión sobre cómo intrfunciona. Por lo tanto, debería poder realizar KILLel proceso, pero eso puede no darle mucha utilidad.

No pude encontrar la discusión sobre por qué se eliminó la opción. ¿Puedes matar-MATAR tu proceso?

Parte de mi respuesta es la opinión, basada en la experiencia. Cuando tenga datos, intentaré (intentar recordar) vincularlos.

1. NFS 4 se considera una mejora con respecto a las versiones 2 y 3. Sin embargo, todavía no he visto un caso de uso sólido para necesitar las mejoras. Tal vez sea porque pretendo exportar sistemas de archivos a clientes Windows con Samba y a clientes Unix / Linux con NFS.
2. No lo recomendaría soften casi ninguna circunstancia. Permite que los datos se descarten por error . En cambio, sugeriría hard,intr.
3. Como señala, intrno es válido para NFS 4, pero parece que este es un cambio de kernel en lugar de uno de NFS.
4. El NFS Automounter ( autofs) funciona bien para mis casos de uso con las versiones NFS 2 y 3, y se las arregla para ayudar a proteger mis sistemas cliente de fallas del servidor al montar los sistemas de archivos NFS solo cuando son necesarios.

Mi sugerencia para usted sería considerar pasar de NFS 4 a NFS 3 y ver si eso ayuda a su caso de uso particular. No pienses en ello como una rebaja.