¿Evitar que los montajes NFS rotos bloqueen un directorio?

17

Tengo una configuración algo interesante: un servidor con múltiples servidores NFS remotos montados en una carpeta, y esa carpeta luego se reexporta a través de Samba. Piense en ello como un proxy compartido, manteniendo todas las carpetas compartidas en un solo lugar.

Sin embargo, mi problema es que cada vez que uno de los montajes se cae (se reinicia el servidor, se reinicia el servicio, se elimina el disco duro externo que el servidor estaba exportando, etc.) cualquier intento de leer los bloques de montaje para siempre. Esto también significa que la ejecución lsen ese directorio se congela y los usuarios que se conectan a través de Samba también se congelan. Esto también ha provocado el bloqueo de algunas de mis tareas cron que casi ha bloqueado el servidor porque tenía cientos de procesos bloqueados. Esto se está volviendo muy molesto, ya que generalmente tengo que abrir un terminal que no está esperando para lsterminar (no puedo cancelarlo), ejecutar for i in *; do sudo umount -l -f $i; done;, esperar que funcione, solucionar el problema y luego volver a montar todo.

¿Hay alguna manera de montar un recurso compartido NFS con la estipulación de que si la conexión falla por alguna razón (preferiblemente con un período de reintento), el montaje se desmonta o al menos no se bloquea?

TheLQ
fuente
¿Puedes publicar /etc/fstab?
Karlson

Respuestas:

19

Normalmente, al montar NFS, es una buena idea tener banderas configuradas de forma similar a esto:

bg,intr,soft
   bg      If  the  first  NFS  mount  attempt times out, retry the mount in the 
           background.  After a mount operation is backgrounded, all subsequent mounts
           on the same NFS  server  will  be  backgrounded immediately, without first
           attempting the mount.  A missing mount point is treated as a timeout, to
           allow for nested NFS mounts.
   soft    If  an  NFS  file operation has a major timeout then report an I/O error
           to the calling program.  The default is to continue retrying NFS file
           operations indefinitely.
   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.

Además puede establecer:

timeo=5,retrans=5,actimeo=10,retry=5

lo que debería permitir que el montaje NFS se agote y hacer que el directorio sea inaccesible si el servidor NFS deja la conexión en lugar de esperar en los reintentos.

Eche un vistazo a este enlace para obtener más información sobre las opciones de montaje NFS

Karlson
fuente
usando solo bg, intr, soft todavía deja una caída de 120 segundos en Fedora 20. Pero agregar timeo = 5, retrans = 5, actimeo = 10, retry = 5 lo hace agradable y rápido. ¡Gracias!
Greg Sheremeta
44
"La opción de montaje intr / nointr está en desuso después del núcleo 2.6.25. Solo SIGKILL puede interrumpir una operación NFS pendiente en estos núcleos, y si se especifica, esta opción de montaje se ignora para proporcionar compatibilidad con versiones anteriores de los núcleos". "Esta opción se proporciona por compatibilidad con versiones anteriores. Se ignora después del kernel 2.6.25".
David C. Bishop
1
@ DavidC.Bishop, ¿de dónde es esa cita? ¿Puedes dar un enlace? Gracias.
Becko
2
@becko: La cita de SIGKILL es de la página de manual de nfs (solo busque 'nointr'). Las versiones más recientes, como la de mi sistema, ahora simplemente leen "Esta opción se proporciona por compatibilidad con versiones anteriores. Se ignora después del kernel 2.6.25". Linky .
David C. Bishop