Debian 13: Tiempos de espera de NFS — las opciones de montaje que mejoran la estabilidad (y cuándo no lo hacen)

diciembre 13, 2025 • febrero 3, 2026 • Lectura: 29 min • Views: 7

¿Te fue útil?

Tus hosts Debian 13 funcionan bien hasta que dejan de hacerlo: un trabajo de compilación se queda congelado, un nodo web deja de rotar logs, o
todo un worker de Kubernetes parece “arriba” pero no puede ls un directorio. Revisas la aplicación. Nada.
Revisas la CPU. Aburrido. Entonces lo encuentras: nfs: server foo not responding, still trying.

Los timeouts de NFS se sienten como una traición porque rara vez son una sola cosa. Son una negociación entre el cliente del kernel,
el servidor, la red y el almacenamiento que haya detrás del servidor. Las opciones de montaje pueden hacer que esa negociación sea justa—o
simplemente amordazar al mensajero mientras el incendio se propaga. Hagamos lo primero.

Qué significa realmente “timeout de NFS” en Linux

En Debian 13, “timeout de NFS” suele aparecer como un síntoma del lado cliente: las RPC hacia el servidor no completaron
en el tiempo esperado y el cliente está reintentando (o renunciando, si lo forzaste). El detalle clave:
la mayoría de los “timeouts” no son un único temporizador que expira una vez. Son una serie de retransmisiones, retrocesos exponenciales
y intentos de recuperación de estado a través de múltiples capas.

El cliente puede estar esperando por:

Entrega en la red: pérdida de paquetes, coincidencia MTU incorrecta, buffers congestionados, enlaces inestables, rarezas de ECMP.
Procesamiento RPC en el servidor: hilos nfsd saturados, sistema de ficheros exportado bloqueado por I/O en disco, demoras del gestor de locks.
Almacenamiento detrás del servidor: reconstrucción RAID, pool thin-provisioned sin espacio, SSD sobrecargado, ARC mal dimensionado, snapshots patológicos.
Recuperación de estado: renovación de leases NFSv4, revocación de delegaciones, cambios de client ID tras reboot, periodos de gracia.

Los clientes NFS en Linux también pueden parecer “colgados” mientras se comportan según el diseño. Un hard mount seguirá reintentando I/O
indefinidamente (o durante mucho tiempo) porque la corrección importa más que fallar rápido. Eso no es un problema de timeout;
es descubrir la semántica que has comprado.

Las preguntas que importan:

¿El cliente reintenta porque el servidor es lento, o porque la red está perdiendo paquetes?
¿El cliente está bloqueado en sleep no interrumpible (D) en llamadas NFS?
¿El servidor está vivo pero su almacenamiento subyacente está atascado?
¿Elegiste semánticas de montaje que coinciden con la tolerancia de la carga de trabajo a corrupción frente a tiempo de inactividad?

Una idea parafraseada de Werner Vogels (CTO de Amazon): Todo falla; diseña para que la falla sea rutinaria y recuperable.

Hechos interesantes y contexto histórico

NFS precede a la “nube” por décadas: NFS apareció a mediados de los 80, diseñado para LAN donde “rápido” era 10 Mbps y un servidor beige.
NFSv3 es “relativamente sin estado” a propósito: el servidor no mantiene estado por cliente sobre archivos abiertos como SMB; reduce la complejidad del servidor pero desplaza el dolor al locking y a los reintentos del cliente.
NFSv4 integró el locking: NLM/lockd se separó en v2/v3; v4 integró el locking y añadió un protocolo con estado y leases.
El ajuste de timeouts existe por RPC sobre UDP: el NFS temprano dependía mucho de UDP; el comportamiento de retransmisión importaba mucho. TCP mejoró el transporte pero no eliminó los bloqueos del servidor.
“Stale file handle” es una característica, no un bug: los filehandles NFS codifican identidad del servidor; si el inode desaparece o el export se movió, el cliente no puede fingir que es el mismo archivo.
Las guerras de rsize/wsize fueron reales: redes antiguas y NICs podían destrozar el rendimiento con tamaños mal elegidos; los valores por defecto modernos son más sensatos pero jumbo/overlays todavía pueden morder.
nconnect es relativamente nuevo: múltiples conexiones TCP por montaje mejoran el paralelismo; excelente en clientes ocupados, pero puede amplificar carga en servidores frágiles.
Los timeouts de NFS suelen culpar a la capa equivocada: un array de almacenamiento que hace failover de controladora se ve idéntico a “jitters de red” desde el punto de vista del cliente.

Guion de diagnóstico rápido (primero/segundo/tercero)

Cuando la gente dice “NFS está haciendo timeouts”, la jugada ganadora es dejar de debatir flags de montaje y empezar a estrechar el cuello de botella.
Este es el orden que encuentra respuestas rápidamente sin hervir el océano.

Primero: confirma el modo de fallo en el cliente (¿está bloqueando? ¿reintentando? ¿fallando rápido?)

Revisa logs del kernel buscando “not responding” y transiciones a “OK”.
Comprueba si procesos están atascados en estado D en llamadas NFS.
Consulta estadísticas RPC del cliente NFS: picos de retrans frente a tráfico normal.

Segundo: aísla red vs CPU del servidor vs almacenamiento del servidor

Ping no es suficiente; revisa pérdida de paquetes, problemas de ruta MTU y retransmisiones TCP.
En el servidor, revisa saturación de hilos nfsd y carga del sistema con I/O wait.
En el servidor, comprueba latencias del sistema de ficheros subyacente (por ejemplo, iostat) y busca dispositivos bloqueados.

Tercero: decide si las opciones de montaje son mitigación o enmascaramiento

Usa opciones de montaje para alinear semánticas (hard vs soft, intr, timeo/retrans) con las necesidades de la carga.
No “arregles” bloqueos de almacenamiento con soft salvo que aceptes escrituras parciales y riesgo de corrupción a nivel de aplicación.
Prefiere opciones que mejoren la recuperación y reduzcan comportamientos patológicos: bg, nofail, timeo sensato, versión de protocolo adecuada y ordenación con systemd.

Opciones de montaje que ayudan a la estabilidad (y las trampas)

La estabilidad en NFS no es solo “no hacer timeouts.” Es “cuando algo es lento o está roto, fallar de una forma que el sistema pueda
sobrevivir.” Eso significa valores por defecto correctos para uso general y excepciones dirigidas para cargas que los toleren.

Hard vs soft: elige semánticas, no sensaciones

hard significa que el cliente reintenta I/O hasta que tenga éxito. Por eso ves “still trying”.
Es la elección correcta para integridad de datos y la mayoría de cargas POSIX. También puede congelar hilos de aplicación
si el servidor desaparece. Ese es el precio.

soft significa que el cliente abandona después de reintentos y devuelve un error a la aplicación.
Suena “estable” hasta que te das cuenta: algunas aplicaciones tratan los errores de I/O como transitorios y siguen, posiblemente tras
escrituras parciales o lecturas cortas inesperadas. No hiciste a NFS más fiable; hiciste que el fallo sea más rápido y más creativo.

Orientación con opinión:

Usa hard para cualquier cosa que escriba datos importantes: bases de datos, colas de mensajes, almacenes de artefactos, directorios home.
Considera soft solo para contenido mayormente de solo lectura, cacheable y no crítico donde los errores sean aceptables y gestionados (por ejemplo, un render farm que reobtiene inputs).
Si eliges soft, deja las expectativas por escrito con los responsables de las aplicaciones. Estás cambiando semánticas, no afinando.

Broma #1: Un montaje soft es como una regla de firewall “temporal”: todos la olvidan hasta que el informe del incidente busca un culpable.

`timeo` y `retrans`: qué controlan realmente

En NFS de Linux, timeo no es “el tiempo antes del fallo.” Es el timeout base de RPC antes de reintentar, en décimas de segundo
en muchas configuraciones (comúnmente: timeo=600 significa 60 segundos). La espera efectiva puede ser mucho mayor debido al backoff exponencial y reintentos.

retrans indica cuántas veces reintentar una RPC antes de que el cliente escale su comportamiento (y para montajes soft, antes de devolver error).
Reducir timeo puede hacer que el cliente detecte problemas antes, pero también puede aumentar la carga durante la congestión por reintentos más frecuentes.
Aumentar timeo puede reducir tormentas de retransmisiones en redes ruidosas, pero hace que las caídas reales parezcan más largas.

Orientación práctica:

En LAN estables, los valores por defecto suelen ser suficientes. Ajusta solo cuando tengas evidencia: picos de retrans, enlaces WAN, o bloqueos de servidor conocidos.
En enlaces tipo WAN o propensos a pérdidas, un timeo ligeramente mayor puede reducir el thrash; no lo pongas en minutos salvo que disfrutes ver reinicios desesperados.
Si ves pausas breves (unos segundos) por failovers del servidor, no reacciones con valores de timeo diminutos; deja que la recuperación ocurra.

`proto=tcp` y versiones NFS: elige lo que puedas soportar

En Debian moderno, debes usar TCP. UDP es mayormente una pieza de museo a menos que trabajes alrededor de algo realmente extraño.
TCP ofrece mejor comportamiento bajo pérdida y maneja cargas mayores de forma más sensata.

Elección de versión:

NFSv4.x (incluyendo 4.1/4.2) suele ser la mejor opción por defecto: menos puertos, locking integrado, mejor manejo de firewalls.
NFSv3 aún puede ser la opción correcta con servidores legacy, algunos appliances NAS o casos raros. Pero requiere más piezas móviles (rpcbind, mountd, lockd/statd).

Ángulo de estabilidad: la recuperación de estado en v4 puede ser dolorosa durante reinicios del servidor (periodos de gracia), pero es más predecible cuando se configura bien.
v3 puede parecer “más simple” hasta que depures recuperación de locks a las 2 a.m.

`vers=4.1` o `vers=4.2` vs “lo que negocie”

Dejar que cliente y servidor negocien versiones puede estar bien, pero también es así como terminas con degradaciones sorprendentes tras un cambio.
Si operas producción, fija la versión a menos que tengas una razón para no hacerlo.

Fija vers=4.1 si tu servidor funciona bien con 4.1 y no necesitas características de 4.2.
Usa vers=4.2 si ambos soportan y has probado. Algunas características de 4.2 (como copia/clone servidor en algunos stacks) son excelentes; implementaciones defectuosas no lo son.

`actimeo` y caché de atributos: estabilidad vs corrección

actimeo (y los más finos acregmin/acregmax/acdirmin/acdirmax) controlan el cache de atributos.
Aumentar tiempos de caché reduce RPCs de metadatos, lo que puede ayudar bajo carga y reducir la exposición a lentitud transitoria.
También puede hacer que los clientes vean metadatos obsoletos por más tiempo, lo que rompe aplicaciones que esperan consistencia close-to-open.

Casos de uso:

Granjas de compilación y CI que leen dependencias compartidas: aumentar caché de atributos puede ser una ganancia.
Directorios home compartidos con ediciones frecuentes desde varios hosts: no te compliques; mantén valores por defecto o conservadores.

`rsize`/`wsize`: no persigas benchmarks, persigue latencia cola

Tamaños I/O mayores pueden mejorar el throughput pero empeorar la latencia cola si el servidor o la red sufren con ráfagas grandes.
Los valores por defecto modernos suelen ser adecuados. Si afinas, hazlo midiendo y con planes de reversión.

Un patrón común de estabilidad: reduce un poco wsize cuando un servidor frágil cae bajo ráfagas de escritura intensas.
Pero si haces eso, estás tratando síntomas; la solución real es capacidad de servidor/almacenamiento.

`nconnect`: más paralelismo, más formas de sobrecargar un servidor

nconnect=N abre múltiples conexiones TCP por montaje. Puede ayudar dramáticamente en clientes con I/O paralelo,
especialmente cuando un flujo TCP se convierte en cuello de botella.

Compensación de estabilidad:

En servidores robustos, puede reducir timeouts mejorando throughput y reduciendo colas.
En servidores marginales, puede amplificar carga y hacer los bloqueos más frecuentes.

Recomendación: empieza con nconnect=4 para clientes de alto rendimiento si la capacidad del servidor es conocida; monitoriza CPU del servidor, hilos nfsd y latencia.

`noatime`: pequeña ganancia, a veces real

Desactivar actualizaciones atime reduce tráfico de escritura en cargas mayormente de lectura. No solucionará timeouts causados por bloqueos del servidor,
pero puede recortar churn en segundo plano y mejorar la estabilidad bajo carga límite.

Opciones de arranque del sistema: `nofail`, `bg` y timeouts de systemd

Muchos incidentes de “timeout NFS” empiezan como “un host no arranca porque NFS no está listo aún.” Eso no es un problema de rendimiento NFS.
Es ordenación de arranque y manejo de fallos.

nofail permite que el arranque continúe si el montaje no está disponible. Genial para montajes no críticos; peligroso para montajes requeridos.
bg (principalmente para comportamiento tipo NFSv3) pone en background intentos de montaje después de un primer intento, dejando continuar el arranque.
x-systemd.automount crea un automount on-demand; el sistema arranca y monta solo cuando se accede. Es un arma de estabilidad usada con cuidado.
x-systemd.mount-timeout= controla cuánto espera systemd por la unidad de montaje. Puedes evitar minutos de bloqueo en el arranque.

Locking e “interrumpibilidad”: sabe a lo que te apuntas

La vieja sabiduría incluía intr para interrumpir operaciones NFS con señales. Los kernels modernos cambiaron el comportamiento; para muchas configuraciones es por defecto o no tiene significado.
El punto sigue: matar un proceso atascado en I/O NFS no siempre es posible, porque el kernel espera la respuesta del servidor.

Si necesitas “kill siempre funciona”, no quieres semánticas NFS. Necesitas otra arquitectura: buffering local, replicación asíncrona, o un store de objetos.

Broma #2: Afinar timeouts de NFS sin medir el servidor es como arreglar un ascensor lento cambiando la pegatina del botón “cerrar puerta”.

Particularidades de Debian 13: systemd, kernel, valores por defecto

Debian 13 incluye un kernel moderno y un comportamiento de systemd que hace que los montajes NFS se sientan diferentes a la era de “editar fstab, reboot, rezar”.
Los cambios operativos relevantes:

systemd trata los montajes como unidades con dependencias; el orden respecto a network-online.target importa para montajes remotos.
remote-fs.target puede bloquear servicios si los montajes son “requeridos.” Decide explícitamente qué debe bloquear y qué no.
Las utilidades cliente NFS están separadas: el kernel provee el cliente; las herramientas userland ayudan con diagnóstico y configuración. Asegúrate de tener nfs-common en los clientes.

Mi baseline opinada para un cliente de producción “normal” en Debian 13 (NFSv4.1 en LAN) se ve así:

cr0x@server:~$ cat /etc/fstab
nfs01:/export/shared  /mnt/shared  nfs  vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,_netdev,x-systemd.automount,x-systemd.idle-timeout=60  0  0

¿Por qué esta mezcla?

hard mantiene la semántica de datos saneada.
timeo=600,retrans=2 es conservador (no pequeño) y evita martillazos durante momentos breves; ajústalo solo con evidencia.
x-systemd.automount evita situaciones de rehén en el arranque para muchas cargas.
x-systemd.idle-timeout=60 deja que el automount entre en reposo; esto puede reducir estado obsoleto en laptops o nodos efímeros.
_netdev señala “esto depende de la red” para ordenación.

Cuando esta baseline está equivocada:

Si el montaje debe estar disponible antes de que servicios críticos arranquen (por ejemplo, binarios de la app viven allí), automount puede generar latencia sorpresa en el primer acceso. Mejor montar temprano y fallar rápido, o rediseñar.
Si estás en un WAN de alta latencia, puede que necesites timeo mayor y elecciones de caché cuidadosas.
Si tu servidor hace failovers planificados, necesitas probar comportamiento de recuperación bajo carga; flags de montaje no te salvarán de un controlador de almacenamiento que se pausa 45 segundos.

12+ tareas prácticas: comandos, salidas, decisiones

A continuación hay tareas operativas que realmente ejecutaría. Cada una incluye qué buscar y qué decisión impulsa.
Ejecútalas primero en un cliente y luego en el servidor. Estás construyendo una línea temporal e aislando la capa que falla.

Tarea 1: Confirma qué está montado y con qué opciones

cr0x@server:~$ findmnt -t nfs,nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET       SOURCE              FSTYPE OPTIONS
/mnt/shared  nfs01:/export/shared nfs4  rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.2.15,local_lock=none

Qué significa: estás usando NFSv4.1 sobre TCP con un montaje hard; el cliente reintentará. rsize/wsize muestran valores negociados.

Decisión: si ves inesperado vers=3, udp o falta de hard, corrige la definición de montaje antes de perseguir fantasmas.

Tarea 2: Observa logs del kernel por “not responding” y “OK”

cr0x@server:~$ sudo journalctl -k -g 'nfs' -S -2h
Dec 29 09:12:41 client01 kernel: nfs: server nfs01 not responding, still trying
Dec 29 09:13:10 client01 kernel: nfs: server nfs01 OK
Dec 29 09:27:02 client01 kernel: nfs: server nfs01 not responding, still trying

Qué significa: tienes stalls intermitentes, no una caída limpia. La línea “OK” sugiere que ocurre recuperación.

Decisión: stalls intermitentes te empujan a investigar latencia del servidor/almacenamiento y pérdida en la red, no DNS o typos en fstab.

Tarea 3: Comprueba procesos atascados en sleep no interrumpible (estado D)

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | awk '$2=="D"{print}' | head
21453 D  tar          nfs_wait_on_request      tar -cf /mnt/shared/backup.tar /var/lib/app
30112 D  rsync        rpc_wait_bit_killable    rsync -a /data/ /mnt/shared/data/

Qué significa: procesos de usuarios están bloqueados esperando NFS/RPC. Matarlos puede no funcionar hasta que el I/O del kernel complete o agote timeouts según semántica.

Decisión: si muchos procesos están en D, trata esto como un incidente de infraestructura, no un bug de aplicación. Procede a estadísticas RPC y chequeos del servidor.

Tarea 4: Inspecciona estadísticas RPC cliente NFS por retransmisiones

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
128904     8421       0

Client nfs v4:
null         read         write        commit       open         open_conf
0            48210        19342        0            188          0

Qué significa: retrans es alto en relación con calls (aquí ~6.5%). Eso suele indicar pérdida de paquetes, congestión o stalls del servidor lo bastante largos para disparar reintentos.

Decisión: si retrans está casi a cero, el problema puede ser bloqueo a nivel de aplicación o servidor sin pérdida de paquetes (todavía posible). Si retrans es alto, prioriza red y capacidad de respuesta del servidor.

Tarea 5: Confirma conectividad básica de ruta y detecta pérdidas (no solo latencia)

cr0x@server:~$ ping -c 50 -i 0.2 nfs01
PING nfs01 (10.10.2.20) 56(84) bytes of data.
64 bytes from 10.10.2.20: icmp_seq=1 ttl=64 time=0.424 ms
64 bytes from 10.10.2.20: icmp_seq=2 ttl=64 time=0.391 ms
...
--- nfs01 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 10047ms
rtt min/avg/max/mdev = 0.320/0.410/0.690/0.072 ms

Qué significa: sin pérdida ICMP obvia; buena señal, no prueba. ICMP puede ser priorizado diferente al tráfico NFS.

Decisión: si hay pérdida aquí, tienes un incidente de red. Si no, sigue con TCP y contadores de interfaz.

Tarea 6: Revisa contadores de interfaz por drops y errores en el cliente

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      912345678  854321      0    412       0   12345
    TX:  bytes packets errors dropped carrier collsns
      812345001  743210      0      0       0       0

Qué significa: RX drops indican congestión, desbordo de ring buffer o problemas upstream. Los drops se correlacionan fuertemente con retrans RPC.

Decisión: si los drops aumentan durante incidentes, investiga opciones de offload de la NIC, carga del host, congestión de switch y MTU. No toques los timeouts NFS aún.

Tarea 7: Verifica consistencia de MTU y busca pistas de fragmentación

cr0x@server:~$ ip link show dev eth0 | grep -E 'mtu|state'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

Qué significa: MTU es 1500. Si tu red usa jumbo frames de forma inconsistente, puedes obtener problemas PMTU que parecen “stalls aleatorios de NFS.”

Decisión: si sospechas mismatch de MTU, estandariza temporalmente a 1500 extremo a extremo o asegura que jumbo sea consistente (hosts, switches, bonds, VLANs, overlays).

Tarea 8: Comprueba retransmisiones TCP en el cliente

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpTimeouts'
TcpRetransSegs                 1932
TcpTimeouts                    41

Qué significa: retrans y timeouts TCP sugieren pérdida en la red o congestión severa—no puramente un problema de servidor NFS.

Decisión: si estos suben durante incidentes, enfócate en la ruta de red y colas NIC del host. Si están estables, céntrate más en latencia de servidor/almacenamiento.

Tarea 9: Confirma que el servidor es alcanzable en los puertos/protocolo NFS esperados

cr0x@server:~$ sudo ss -tn dst 10.10.2.20 | head
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port  Process
ESTAB  0      0      10.10.2.15:51144    10.10.2.20:2049
ESTAB  0      0      10.10.2.15:51146    10.10.2.20:2049

Qué significa: conexiones TCP activas al puerto 2049 (NFS). Si esperabas NFSv4 y ves un lío de puertos auxiliares, podrías estar en v3.

Decisión: si las conexiones flaquean o Recv-Q crece, puedes tener lentitud del servidor o colas en la red. Sigue con métricas del servidor.

Tarea 10: En el servidor, revisa saturación de hilos nfsd y salud básica

cr0x@server:~$ sudo cat /proc/net/rpc/nfsd | head -n 20
rc 0 0 0
fh 0 0 0 0 0
io 123456 654321
th 64 0 0.000 0.000 0.000 0.000 0 0 0 0
ra 32 0 0 0 0 0 0 0 0 0 0 0
net 0 0 0 0
rpc 1234 0 0 0 0 0 0 0 0 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc4 2 0 0

Qué significa: la línea th muestra número de hilos nfsd (aquí 64). Si este número es pequeño en un servidor ocupado, puedes tener colas.

Decisión: si hilos nfsd son pocos, auméntalos apropiadamente (y asegúrate de que la CPU esté disponible). Si hay muchos hilos pero persisten stalls, mira latencia del almacenamiento subyacente.

Tarea 11: En el servidor, detecta I/O wait y almacenamiento bloqueado rápidamente

cr0x@server:~$ sudo iostat -xz 1 5
Linux 6.10.0 (nfs01)  12/29/2025  _x86_64_ (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    4.20   38.50    0.00   45.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         210.0  16800.0     0.0   0.00    8.20    80.0     95.0   9200.0     0.0   0.00   62.30    96.8    7.10   92.0

Qué significa: alto %iowait junto con alto w_await y %util sugiere saturación o latencia del almacenamiento.

Decisión: si el almacenamiento es el cuello de botella, las opciones de montaje no lo curarán. Necesitas capacidad de almacenamiento, caché, ajuste de colas o modelado de carga.

Tarea 12: Confirma exports y acceso por cliente en el servidor

cr0x@server:~$ sudo exportfs -v
/export/shared  10.10.2.0/24(rw,wdelay,root_squash,sec=sys,async,no_subtree_check,fsid=0)
/export/backups 10.10.2.15(rw,root_squash,sec=sys,sync,no_subtree_check)

Qué significa: muestra opciones de export. Observa la diferencia entre async y sync, y el alcance por cliente/subred.

Decisión: si ves accidentalmente sync en un export ocupado (o viceversa), has encontrado una palanca de estabilidad/rendimiento—manéjala con cuidado y prueba. Verifica también que los clientes correctos estén permitidos; denegaciones de acceso pueden parecer timeouts a las apps.

Tarea 13: Revisa logs del servidor NFS por periodos de gracia y eventos de recuperación

cr0x@server:~$ sudo journalctl -u nfs-server -S -2h | tail -n 30
Dec 29 09:11:58 nfs01 systemd[1]: Starting NFS server and services...
Dec 29 09:11:58 nfs01 kernel: NFSD: starting 64-second grace period (net ffffffff9a6a0000)
Dec 29 09:12:02 nfs01 systemd[1]: Started NFS server and services.

Qué significa: los periodos de gracia afectan a clientes NFSv4 reclamando locks. Durante la gracia, algunas operaciones pueden bloquearse o fallar de formas específicas.

Decisión: si los timeouts se agrupan alrededor de reinicios/failovers del servidor, necesitas diseñar para la gracia/recuperación: reintentos en la app, ventanas de mantenimiento o HA que preserve estado correctamente.

Tarea 14: Valida mapeo de nombres y mapeo de IDs (dolor NFSv4 que parece “colgado”)

cr0x@server:~$ nfsidmap -c
cr0x@server:~$ nfsidmap -l | head
0x00000001: user@domain
0x00000002: nobody@domain

Qué significa: las caches de idmap pueden quedar obsoletas o mal configuradas, causando anomalías de permisos que se reportan como “NFS roto.”

Decisión: si los usuarios ven “permission denied” u ownership extraño en rutas montadas, verifica idmapping y una estrategia UID/GID consistente antes de tocar timeouts.

Tarea 15: Prueba latencia percibida con un bucle controlado de I/O pequeño

cr0x@server:~$ time bash -c 'for i in {1..200}; do echo $i > /mnt/shared/.lat_test.$i; done'
real    0m2.913s
user    0m0.059s
sys     0m0.351s

Qué significa: comprobación rápida para escrituras sincrónicas pequeñas. Repite durante un incidente; si real salta mucho, estás viendo latencia de almacenamiento o procesamiento del servidor.

Decisión: si escrituras pequeñas pasan a segundos-minutos, el ajuste de montaje no lo solucionará. Investiga discos del servidor, opciones de export (sync/async) y carga del servidor.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición errónea (“los hard mounts son el problema”)

Una empresa mediana tenía clientes Debian montando un export NFS compartido para artefactos de CI. Las compilaciones empezaron a “congelarse aleatoriamente.”
El equipo de plataforma notó procesos en D y concluyó que el montaje era el problema. Cambiaron el montaje a soft,timeo=50,retrans=2.

Los congelamientos pararon. Los tickets se calmaban. Todos felicitaron el “arreglo de estabilidad.” Dos semanas después, ingeniería de releases encontró artefactos corruptos:
tarballs que se desempaquetaban con archivos faltantes, checksums que no coincidían y algunas compilaciones que “habían tenido éxito” pero no eran reproducibles.
Los logs mostraron EIO ocasional en syscalls de escritura que las herramientas de build no trataron como fatales porque no estaban diseñadas para almacenamiento poco fiable.

La causa subyacente era un array de almacenamiento detrás del servidor NFS que tenía picos de latencia periódicos durante limpieza de snapshots.
El servidor no estaba “caído”, simplemente a veces no podía atender RPCs a tiempo, así que los clientes retransmitían y luego—con soft—renunciaban.

Revirtieron a hard, luego arreglaron el culpable real: la programación de snapshots y la holgura de rendimiento del array.
También añadieron verificación de artefactos y declararon “errores de I/O son fatales” como política explícita en la pipeline de CI.
La lección perdurable no fue “nunca uses soft.” Fue “no trates semánticas como perillas de tuning.”

Mini-historia 2: La optimización que salió mal (caché agresiva y jumbo frames)

Otra organización tenía un servidor NFS rápido y quería reducir la carga de metadatos. Alguien afinó el cache de atributos:
actimeo=60 en la flota, además de mayores rsize/wsize y habilitar jumbo frames en hosts nuevos.
El throughput se veía bien en tests sintéticos. Menos RPCs, más MB/s. Se hicieron diapositivas. Casi hubo ascensos.

Luego un subconjunto de clientes empezó a ver colgados misteriosos y “server not responding” en horas punta.
No todos los clientes. No todo el tiempo. El tipo de problema que convierte a ingenieros confiados en aficionados de astrología.

El problema fue inconsistencia de MTU en un par de puertos de switch en un leaf.
Algunos caminos soportaban jumbo, otros descartaban silenciosamente paquetes sobredimensionados. La detección PMTU de TCP no se recuperó bien debido a
mensajes ICMP “fragmentation needed” filtrados en un segmento de firewall que “no debía estar en la ruta.”

Los tweaks de caché enmascararon el problema al principio (menos llamadas de metadatos), pero los I/O mayores más jumbo hicieron el hoyo negro más doloroso.
Arreglar la consistencia de MTU y permitir los ICMP relevantes restauró la estabilidad. Mantuvieron caché moderada, pero dejaron de tratar la red como una alfombra mágica siempre correcta.

Mini-historia 3: La práctica aburrida que salvó el día (automount + orden explícito)

Una compañía con finanzas cercanas tenía la costumbre: cada montaje NFS en fstab usaba _netdev,x-systemd.automount,x-systemd.mount-timeout=15,
y los montajes “críticos” los montaba una unidad dedicada que requería network-online.target más una comprobación de salud.
No era glamoroso. No mejoró benchmarks. Era básicamente supervisión adulta para el arranque.

Un día, un switch core hizo reboot inesperado. La mitad de la flota perdió red por un par de minutos.
Los servicios dramáticos fallaron; los aburridos se recuperaron. Importante: los hosts no quedaron bloqueados en el arranque ni bloquearon servicios no relacionados.
Cuando el servidor NFS volvió a ser alcanzable, automount restableció montajes bajo demanda.

Aún tuvieron errores de aplicación (por la caída de red), pero no tuvieron un desastre de segundo orden: arranques pegados, despliegues atascados
y reinicios en pánico que ralentizaron la recuperación. El postmortem tuvo una línea rara: “La configuración de montajes se comportó como diseñada.”

La práctica no era ingeniosa. Era correcta. Y en producción, “correcto” envejece mejor que “ingenioso.”

Errores comunes: síntoma → causa raíz → solución

1) Spam “server not responding”, pero ping muestra OK

Síntoma: logs del kernel muestran NFS not responding; ICMP ping muestra sin pérdida.

Causa raíz: stalls de almacenamiento del servidor o saturación de nfsd; ICMP no refleja latencia RPC de la aplicación.

Solución: revisa iostat del servidor por await/util altos; verifica hilos nfsd; mejora holgura de almacenamiento. No ajustes timeo a ciegas.

2) Arranques que cuelgan esperando NFS

Síntoma: nodo reiniciado se queda en “A start job is running for /mnt/shared”.

Causa raíz: montaje requerido sin ordenación/timeouts adecuados en systemd; red no “online” aún, o servidor NFS no disponible.

Solución: usa _netdev, x-systemd.automount y x-systemd.mount-timeout=. Para montajes verdaderamente requeridos, controla servicios dependientes y falla rápido.

3) “Permission denied” aleatorio tras un montaje limpio

Síntoma: el montaje procede; usuarios ven ownership erróneo o acceso denegado; la gente llama a esto “NFS inestable”.

Causa raíz: mismatch de idmapping NFSv4 (dominio), UID/GID inconsistentes, cache idmap obsoleta.

Solución: estandariza identidad (LDAP/SSSD o IDs locales consistentes), configura dominio idmap, limpia caches con nfsidmap -c.

4) Procesos clientes atascados en D-state por horas

Síntoma: procesos inmatables; sistema “arriba” pero inutilizable.

Causa raíz: semántica hard + servidor inalcanzable o I/O atascado; a veces agravado por hoyo negro en la red.

Solución: restaura servidor/red. Si esto es operacionalmente inaceptable, rediseña: buffering local, pipelines asíncronos o separar rutas críticas de NFS.

5) “Stale file handle” tras mantenimiento o cambios de export

Síntoma: aplicaciones fallan en rutas existentes; nuevos montajes funcionan.

Causa raíz: objetos del FS en el servidor cambiaron/moveron; export remapeado; FS subyacente recreado; snapshots restaurados.

Solución: remonta clientes; evita cambiar identidad de la raíz del export; usa exports estables; documenta pasos de mantenimiento que invaliden handles.

6) Cambiar a `soft` “arregla” timeouts pero provoca problemas silenciosos de datos

Síntoma: menos colgados; más tarde aparecen archivos corruptos o salidas incompletas sin fallos claros.

Causa raíz: mounting soft devuelve errores a mitad de operación; la aplicación no lo trata como fatal; persisten resultados parciales.

Solución: revierte a hard para escrituras; añade cheques de integridad end-to-end; arregla el servidor/red que causa retrans.

7) nconnect mejora throughput y luego empeoran timeouts

Síntoma: mayor throughput en pruebas; bajo carga producción, el servidor se vuelve menos responsivo; aparecen timeouts.

Causa raíz: mayor paralelismo amplifica CPU del servidor, nfsd o carga del almacenamiento; las colas aumentan latencia cola.

Solución: reduce nconnect, aumenta capacidad del servidor o aísla cargas; mide latencia y saturación de hilos del servidor.

Listas de verificación / plan paso a paso

Checklist A: estabiliza primero, luego afina

Confirma semántica del montaje: mantén hard para todo lo que escriba datos importantes.
Evita rehenes en arranque: añade _netdev,x-systemd.automount,x-systemd.mount-timeout=15 para montajes no críticos.
Fija protocolo/versión: elige vers=4.1 o vers=4.2 deliberadamente; aplica proto=tcp.
Mide retrans: usa nfsstat -c y nstat antes de cambiar timeo.
Arregla la capa lenta: pérdida de red, saturación de CPU del servidor o latencia de almacenamiento. Las opciones de montaje no son caballo de fuerza.

Checklist B: decisiones de opciones de montaje por carga

Bases de datos en NFS: evítalas si puedes; si te fuerzas, usa hard, caché conservadora, valida garantías del servidor y prueba failover.
Directorios home: hard, valores por defecto de caché, céntrate en HA del servidor y estabilidad de la red.
Dependencias compartidas de solo lectura: considera ajustar caché de atributos; considera x-systemd.automount para evitar problemas de arranque.
Nodos de cómputo efímeros: automount con idle timeout reduce estado obsoleto y hace reboots menos dramáticos.
Enlaces WAN: acepta mayor latencia; ajusta timeo modestamente hacia arriba; considera capas de caché local en lugar de pretender que el WAN es LAN.

Paso a paso: un plan sensato para cambiar opciones de montaje

Elige un cliente como canario. No hagas rollout a toda la flota para aprender.
Registra la línea base: findmnt, nfsstat -c, nstat, y un bucle pequeño de I/O con tiempo.
Cambia una dimensión (por ejemplo, fija vers=4.1 o añade x-systemd.automount).
Reprueba bajo carga; vigila iostat del servidor y estadísticas nfsd.
Despliega gradualmente. Mantén instrucciones de rollback en el ticket, no en la memoria de alguien.

FAQ

1) ¿Debo usar `hard` o `soft` para evitar “colgados”?

Usa hard para corrección, especialmente en escrituras. soft evita bloqueos indefinidos devolviendo errores,
pero cambia semánticas y puede causar corrupción de datos en aplicaciones mal diseñadas para almacenamiento poco fiable.

2) ¿Cuáles son buenos valores por defecto para `timeo` y `retrans`?

Empieza con los valores por defecto salvo que tengas evidencia. Un par conservador común es timeo=600,retrans=2 para LAN.
Si estás en un enlace ruidoso o de alta latencia, aumenta timeo modestamente; no subas solo reintentos sin medir.

3) ¿Por qué veo “server not responding” y luego “OK”?

Porque el cliente reintenta RPCs y el servidor responde finalmente. Ese patrón suele indicar pérdida de red transitoria,
sobrecarga del servidor o picos de latencia del almacenamiento detrás del servidor.

4) ¿Hace `x-systemd.automount` a NFS más fiable?

Hace que el arranque y el inicio de servicios sean más resistentes al evitar dependencia dura en el éxito inmediato del montaje. No arregla un servidor lento,
pero evita que un servidor lento rompa partes no relacionadas del sistema.

5) ¿Puedo “arreglar” timeouts NFS cambiando `rsize`/`wsize`?

A veces puedes reducir síntomas, especialmente en redes o appliances frágiles, pero no es una solución de causa raíz.
Ajusta para latencia cola y estabilidad, no para throughput pico.

6) ¿NFSv4 siempre es mejor que NFSv3?

No siempre, pero generalmente sí. NFSv4 es más fácil de firewallizar y tiene una historia de protocolo más limpia. NFSv3 puede ser adecuado en entornos estables,
pero añade servicios auxiliares y puertos, lo que aumenta modos de fallo operacionales.

7) ¿Qué significa cuando procesos están en estado `D`?

Están esperando I/O del kernel que no se puede interrumpir fácilmente. Si es relacionado con NFS, el kernel espera la finalización de RPC.
Soluciona la conectividad/estancamiento del servidor; no esperes que kill -9 lo solucione.

8) ¿Puede el firewall/NAT causar timeouts NFS aunque existan conexiones?

Sí. Firewalls stateful que cierran flujos inactivos, ruteo asimétrico, hoyos PMTU y ICMP filtrado pueden causar stalls que parecen “NFS inestable.”
Por eso verificas retrans TCP y drops de interfaz temprano.

9) ¿Cuándo es apropiado usar `nofail`?

Para montajes que son útiles pero no imprescindibles para el arranque o salud de servicios centrales—como herramientas compartidas opcionales o caches.
No lo uses para montajes críticos a menos que también implementes chequeos de salud explícitos en tus servicios.

10) Si necesito “nunca bloquear”, ¿qué debo usar en lugar de NFS?

Usa almacenamiento local con replicación, o una arquitectura que tolere la falla de almacenamiento remoto: object storage, artefactos direccionados por contenido,
o buffering write-behind con garantías claras de durabilidad. NFS es excelente, pero no es una alfombra mágica.

Conclusión: qué hacer a continuación

Si extraes una lección operativa de los timeouts NFS en Debian 13, que sea esta: las opciones de montaje no son una cura,
son un contrato. Define primero el contrato (hard vs soft, versión de protocolo, comportamiento en el arranque), luego mide dónde el sistema está realmente lento.

Pasos prácticos que puedes hacer esta semana:

Inventaría todos los montajes NFS con findmnt; estandariza en TCP y fija versiones donde corresponda.
Añade x-systemd.automount y timeouts de montaje para montajes no críticos para prevenir rehenes en arranque/servicios.
Construye un “paquete mínimo de incidentes NFS”: nfsstat -c, nstat, ip -s link, logs kernel cliente, iostat del servidor, y /proc/net/rpc/nfsd.
Realiza una prueba controlada de failover/reboot del servidor NFS y observa el comportamiento cliente, incluyendo periodos de gracia, bajo carga.
Cuando debas afinar timeo/retrans, hazlo como experimento con un canario, antes que convertirlo en religión.