Compartir archivos en Linux: NFS vs SMB — Elige el que no se cuelgue

Qué suele significar “se cuelga aleatoriamente”

Cuando la gente dice “el recurso compartido se cuelga”, normalmente se refieren a una de tres cosas:

• Picos de latencia: las operaciones terminan, pero a veces tardan segundos o minutos. Las aplicaciones agotan tiempos de espera, las reintentos se acumulan y se genera un efecto “thundering herd”.
• Esperas I/O duras: un proceso queda bloqueado en espacio kernel (a menudo en estado D) esperando al servidor o a la red. Tu kill -9 no hace nada. No es que el proceso sea obstinado; es el kernel esperando I/O.
• Interbloqueos semánticos: el bloqueo de archivos u oplocks/leases interactúan con el caché del cliente y las expectativas de la aplicación. Todo está “arriba”, pero la app no puede avanzar.

Ambos, NFS y SMB, pueden producir los tres. La diferencia está en dónde aparece la falla, cuán rápido se hace evidente y qué perillas tienes realmente para hacerlo aburrido.

Un modelo mental útil: los sistemas de archivos en red son sistemas distribuidos con bordes afilados. Y los sistemas distribuidos hacen dos cosas bien: fallan de formas nuevas y te obligan a aprender timeouts.

Algunos hechos e historia que realmente importan

Un poco de contexto ayuda porque decisiones de diseño antiguas aparecen hoy como “¿por qué esta opción viene por defecto?”

1. NFS fue diseñado por Sun en los años 80, en una era donde el modelo de seguridad era básicamente “LAN de confianza”. Por eso la seguridad se añadió en capas (AUTH_SYS, luego Kerberos vía RPCSEC_GSS).
2. NFSv3 es sin estado (el servidor no sigue el estado de sesión del cliente igual). Eso puede ser excelente para la recuperación y terrible para expectativas de bloqueo sin servicios adicionales.
3. NFSv4 introdujo estado (bloqueos, delegaciones, sesiones), lo que mejora la semántica pero aumenta los modos de fallo por “estado confundido” cuando la red parpadea.
4. SMB empezó como un protocolo LAN para DOS/Windows y acumuló características empresariales: ACLs ricas, negociación y la suposición de que la identidad importa (usuarios, dominios, servicios de directorio).
5. SMB1 es antiguo e inseguro; los entornos modernos deben usar SMB3.x. SMB3 trajo cifrado, multicanal, mejores comportamientos de rendimiento y menos artefactos arqueológicos.
6. Samba (el servidor SMB en Linux) ha sido apto para producción durante décadas. No es “un parche de compatibilidad”. Es un motor serio de traducción entre identidad y sistema de archivos.
7. El firmado y cifrado de paquetes se volvió algo común con el tiempo en muchos entornos Windows. Eso es bueno para la seguridad, pero puede convertirse en tu impuesto accidental de rendimiento.
8. NFS sobre TCP reemplazó a UDP por cordura en la mayoría de despliegues serios. UDP aún existe en rincones, normalmente justo donde no quieres sorpresas.
9. “Stale file handle” es un error clásico de NFS ligado a cómo NFS identifica archivos y directorios tras cambios en el servidor. No es aleatorio; es que tu servidor/export cambió bajo clientes activos.

Exactamente una cita, porque los ingenieros merecen una línea de poesía: La esperanza no es una estrategia. (idea parafraseada, común en círculos de operaciones)

Cómo falla realmente NFS

NFS es simple hasta que no lo es: el problema de “bloqueado en el kernel”

Los clientes NFS están optimizados para parecer llamadas a sistema de archivos locales. Ese es todo el punto. El VFS del kernel emite un RPC, espera al servidor y devuelve datos. Cuando el servidor está lento, inalcanzable, sobrecargado o pierde paquetes, esas esperas del kernel pueden convertirse en cuelgues de aplicaciones.

La distinción más importante para montajes NFS en producción es: hard vs soft. La segunda más importante es: timeouts y retransmisiones que hagan explícito el modo de fallo en vez de indefinido.

• montajes hard: el cliente reintenta I/O indefinidamente. Esto protege la corrección de datos para muchas cargas, pero puede colgar procesos durante mucho tiempo. “Indefinidamente” no es una vibra; es una política.
• montajes soft: el cliente abandona y devuelve un error a la aplicación tras reintentos. Esto previene colgados infinitos pero arriesga corrupción de datos para algunos patrones de escritura (apps que no esperan fallos parciales).

La mayoría de equipos Linux serios usan hard pero ajustan timeouts y usan automounting sensato para reducir el radio de impacto. Si ejecutas bases de datos sobre NFS, ya sabes que esto es un dolor especial que solo funciona cuando eres extremadamente disciplinado.

Bloqueos: NFSv3 vs NFSv4, y por qué a tu app le importa

El bloqueo de archivos en NFSv3 históricamente implicaba servicios separados (lockd/statd). Si esos están mal configurados, filtrados por un firewall o rotos por NAT, puedes obtener un “funciona pero a veces no” que parece cuelgues aleatorios.

NFSv4 integra el bloqueo en el protocolo y es generalmente la recomendación por defecto para diseños nuevos. Pero NFSv4 es stateful: servidor y cliente mantienen sesiones y bloqueos. Si la red parpadea, puedes obtener expiración de leases, tormentas de recuperación y aplicaciones que se detienen mientras se reconcilia el estado.

Caché del cliente y consistencia de atributos

Los clientes NFS cachean datos y atributos. Eso es bueno; de lo contrario tu servidor de metadatos se derretiría. Pero significa que “creé un archivo y otro host no lo vio” puede ser un comportamiento esperado si tu caché de atributos es agresivo.

En Linux, opciones de montaje como actimeo, acregmin, acregmax y las semánticas v4 alrededor de delegaciones influyen en si obtienes lecturas rápidas o lecturas consistentes. Elegir mal y tendrás sistemas de compilación que se comportan como casas encantadas.

Dos firmas de fallo NFS que aparecen mucho

• Stale file handle: cambios en el sistema de archivos del lado del servidor (p. ej., export movido, inode reutilizado, rollback de snapshot, failover sin file handles estables) invalidan referencias del cliente.
• Tormentas de recuperación: tras un reinicio del servidor o un parpadeo de red, muchos clientes restablecen estado a la vez, haciendo que el servidor parezca lento, lo que hace que los clientes retrocedan, lo que lo hace más lento. Enhorabuena, inventaste tráfico.

Cómo falla realmente SMB

SMB es comunicativo por diseño, pero el SMB moderno es más listo de lo que crees

SMB tiene la reputación entre gente de Linux como “esa cosa de Windows”. En realidad, SMB3 es un protocolo capaz con funciones que NFS a menudo no iguala por defecto: semánticas de ACL más ricas, integración madura con Active Directory, cifrado y algunas opciones de alto rendimiento como multichannel.

Pero SMB también lleva un alto impuesto operativo: identidad, DNS, sincronización de tiempo, controladores de dominio y políticas. Cuando SMB se cuelga, a menudo no es “almacenamiento” en absoluto. Es auth, resolución de nombres o una característica de seguridad haciendo exactamente lo que se le indicó.

Patrones típicos de cuelgue SMB en clientes Linux

• Problemas de renovación de credenciales o tickets: los tickets Kerberos expiran, las renovaciones fallan y tu montaje se vuelve extrañamente lento o da errores.
• Problemas DNS / SPN: el nombre del servidor usado por los clientes no coincide con lo que Kerberos espera, llevando a auth de fallback o fallos repetidos.
• Coste de firmado/cifrado: si el firmado es obligatorio en todas partes y las CPUs son débiles o están ocupadas, SMB se convierte en un benchmark de cripto disfrazado de I/O de archivos.
• Sorpresas con oplocks/leases: el caché cliente de SMB (oplocks/leases) puede mejorar rendimiento pero también causar momentos de “por qué este archivo está bloqueado” cuando las apps esperan semánticas tipo POSIX.

Permisos SMB: el iceberg oculto

Si necesitas ACLs al estilo Windows y comportamiento consistente con identidades AD, SMB suele ser el camino más limpio. NFS también puede lograrlo con ACLs NFSv4 e idmapping, pero “puede” y “agradable” son palabras diferentes.

En clientes Linux que montan shares SMB vía cifs, a menudo mapeas ACLs de Windows a vistas de permisos POSIX. Ese mapeo puede inducir a error a las herramientas. Los usuarios ven chmod “tener éxito” y suponen que cambió algo; puede que no. Esa confusión se convierte en tickets, luego en escalaciones, y luego en ti.

Broma #1: SMB significa Server Message Block, pero en el chat de incidentes a veces parece “Seriously, My Build”.

Elegir el protocolo: reglas para decidir que funcionan a las 3 a.m.

Si eres Linux-a-Linux y quieres el menor drama: por defecto NFSv4.1+

Para clientes Linux y un servidor NAS Linux o empresarial, NFSv4.1 (o más reciente) suele ser la opción más simple y fiable. Está bien soportado, es eficiente y no requiere todo el universo de identidad de Windows.

Úsalo cuando:

• Quieres semánticas POSIX directas la mayor parte del tiempo.
• Puedes gestionar un pequeño conjunto de exports y clientes.
• Te importa el rendimiento por CPU y el comportamiento predecible bajo carga.
• Puedes implementar Kerberos si los datos lo merecen.

Si tu fuente de identidad es Active Directory y los clientes Windows son principales: elige SMB3

Si el negocio vive en AD (ciclo de vida de usuarios, políticas de grupo, clientes Windows), SMB es el camino de menor resistencia. Samba puede servir clientes Linux también, pero el centro de gravedad sigue siendo la semántica y las herramientas de Windows.

Úsalo cuando:

• Necesitas compatibilidad con ACLs estilo NTFS y expectativas de auditoría.
• Necesitas experiencia consistente entre clientes Windows y Linux en el mismo share.
• Necesitas cifrado SMB porque no controlas la ruta de red.

Cuando los “cuelgues” son inaceptables, prefiere el protocolo cuyo fallo puedas mostrar a la app

Esta es la parte incómoda. NFS con montajes hard puede colgar procesos indefinidamente. SMB también puede bloquear, pero en muchos entornos la pila cliente y las herramientas de espacio de usuario hacen más obvio cuando el problema es auth o resolución de nombres.

Si ejecutas trabajos por lotes donde fallar rápido es mejor que colgar, puedes argumentar a favor de SMB con timeouts estrictos o NFS con comportamientos soft cuidadosamente considerados (pero sé conservador).

No mezcles protocolos sobre el mismo sistema de archivos si no conoces las semánticas

Servir el mismo directorio vía NFS y SMB al mismo tiempo es una trampa clásica. Las semánticas de bloqueo y el caché pueden divergir. Si debes hacerlo, prueba exactamente los comportamientos de aplicación que te importan (patrones de rename, escrituras atómicas, bloqueos de archivo y visibilidad de cambios de directorio).

Broma #2: Lo único peor que un montaje NFS colgado es una reunión titulada “Estandaricemos el intercambio de archivos”.

Guion rápido de diagnóstico

No tienes tiempo para admirar el problema. Necesitas localizarlo: cliente, red, servidor o identidad. Aquí hay un orden que minimiza movimientos inútiles.

Primero: confirma que es el sistema de archivos en red e identifica cuál

• Encuentra el tipo de montaje y las opciones de montaje. Confirma si los procesos están bloqueados en ese montaje.
• Verifica si el sistema tiene un I/O wait generalizado o solo un subconjunto de hilos.

Segundo: determina si estás bloqueado en I/O, DNS/auth o almacenamiento del servidor

• Para NFS: busca timeouts RPC, “server not responding”, retransmisiones y stale file handles.
• Para SMB: busca fallos de autenticación, intentos de reconexión, coste de firmado/cifrado y problemas de resolución de nombres.

Tercero: aisla con una operación controlada

• Lee un archivo pequeño desde el share.
• Haz un stat de un directorio con muchas entradas (estrés de metadatos).
• Crea y fsync un archivo pequeño (estrés de semántica de escritura).

Si los metadatos son lentos pero las lecturas están bien, probablemente tienes cuellos de botella distintos a “la red está lenta”. Si las lecturas son lentas pero los metadatos están bien, probablemente estás saturando discos del servidor o el throughput de red.

Cuarto: revisa puntos de saturación

• Cliente: CPU, softirq y retransmisiones TCP.
• Red: drops, errores, desajuste MTU, congestión.
• Servidor: CPU, NIC, latencia de disco, pools de hilos NFS/SMB, backends de auth.

Quinto: decide una mitigación segura

• Si es un problema temporal del servidor: reduce la carga de clientes, limita trabajos por lotes o haz failover si tienes HA.
• Si es un problema de opciones de montaje del cliente: ajusta en un host canario, no en toda la flota.
• Si es auth/DNS/tiempo: arregla la plomería de identidad antes de tocar el ajuste de almacenamiento.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales que puedes ejecutar en un cliente o servidor Linux. Cada una incluye qué significa la salida y qué decisión tomar.

1) Identificar tipo de sistema de archivos y opciones de montaje

cr0x@server:~$ findmnt -t nfs,nfs4,cifs -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET   SOURCE                FSTYPE OPTIONS
/mnt/fs  nas01:/export/builds  nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys
/mnt/hr  //files01/hr          cifs   rw,relatime,vers=3.1.1,cache=strict,username=svc-linux,seal,sign,uid=1000,gid=1000

Significado: Has confirmado qué protocolo estás tratando y el modo de fallo que elegiste (p. ej., hard para NFS). Nota el modo de seguridad (sec=sys vs seal/sign).

Decisión: Si los cuelgues son la queja y NFS está en modo hard, trata los problemas de servidor/red como potencialmente causantes de bloqueos indefinidos. Para SMB, prioriza revisiones de auth/DNS/sobrecoste de seguridad.

2) Ver quién está atascado en el montaje (y si están en estado D)

cr0x@server:~$ ps -eo pid,stat,comm,wchan:30,args | egrep ' D |nfs|cifs' | head
24817 D    tar            nfs_wait_on_request          tar -cf /mnt/fs/archive.tar /mnt/fs/work
25002 D    python3        cifs_writepages              python3 ingest.py
 1121 Ss   nfsiod         nfsiod                       [nfsiod]
 1124 Ss   cifsiod        cifsiod                      [cifsiod]

Significado: D significa sueño no interrumpible, normalmente esperando I/O. wchan sugiere qué subsistema está bloqueando (NFS vs CIFS).

Decisión: Si muchos procesos están en estado D, no “reinicies la app” primero. Solo crearás más hilos bloqueados. Arregla el stall subyacente.

3) Revisa los logs del kernel para pistas NFS/SMB

cr0x@server:~$ dmesg -T | egrep -i 'nfs:|cifs|smb|server not responding|stale|reconnect|rpc'
[Mon Feb  3 10:14:22 2026] NFS: server nas01 not responding, still trying
[Mon Feb  3 10:14:52 2026] NFS: server nas01 OK
[Mon Feb  3 10:18:06 2026] CIFS: VFS: \\files01 has not responded in 180 seconds. Reconnecting...

Significado: NFS y CIFS registran su dolor. “still trying” es una etiqueta de advertencia: los montajes hard esperarán. Las reconexiones SMB pueden bloquear operaciones y amplificar latencia.

Decisión: Si ves repetidos “not responding”, cambia el foco a salud de red/servidor. Si ves bucles de reconexión en SMB, revisa resolución de nombres, auth y disponibilidad del servidor.

4) Estadísticas del cliente NFS: retransmisiones y comportamiento RPC

cr0x@server:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1839201    1843       0

Client nfs v4:
null             read             write            commit
0                923114           11822            11822
open             open_conf        close            setattr
224              0                214              19

Significado: Las retransmisiones no son automáticamente malas, pero si se disparan durante incidentes, tu cuello de botella suele ser pérdida de paquetes, congestión o un servidor sobrecargado que no responde a tiempo.

Decisión: Si retrans sube rápido, deja de “afinar rsize” y empieza a investigar drops en la red, desajuste MTU o saturación del servidor.

5) Vista de exports del servidor NFS y coincidencia de clientes

cr0x@server:~$ showmount -e nas01
Export list for nas01:
/export/builds 10.20.0.0/16
/export/home   10.30.14.0/24

Significado: Confirma que el export existe y que tu subred cliente está permitida.

Decisión: Si un incidente empieza justo después de un movimiento de red, verifica que la IP del cliente sigue en un rango permitido. “Antes funcionaba” no es un estado de configuración.

6) Verifica negociación de versión NFS e identidad del servidor

cr0x@server:~$ rpcinfo -p nas01 | egrep 'nfs|mountd|nlockmgr'
100003    4   tcp   2049  nfs
100003    3   tcp   2049  nfs
100005    3   tcp  20048  mountd
100021    4   tcp  4045   nlockmgr

Significado: Muestra qué versiones del protocolo están disponibles. Si esperabas solo v4 pero ves v3, los clientes podrían estar usando v3 a menos que estén fijados.

Decisión: Fija la versión explícitamente en opciones de montaje para consistencia, especialmente en clientes mixtos.

7) Revisa “stale file handle” y decide si remontar

cr0x@server:~$ ls -l /mnt/fs/work
ls: cannot access '/mnt/fs/work': Stale file handle

Significado: El cliente tiene un file handle que ya no mapea al objeto del servidor. Común tras rollback en el servidor, revert de snapshot, export movido o ciertos failovers.

Decisión: Normalmente se requiere remount. También investiga qué cambió en el servidor; los stale handles son síntomas de acciones operativas, no rayos cósmicos aleatorios.

8) Visibilidad de sesión del cliente SMB (¿qué negociamos?)

cr0x@server:~$ smbstatus -b
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption  Signing
26341   svc-linux    linux         10.20.4.18 (ipv4:10.20.4.18:51234)        SMB3_11           AES-128-GCM required   required

Significado: Confirma el dialecto SMB y si cifrado/firmado están activos. Si el rendimiento es pobre, esto te dice si estás pagando coste criptográfico.

Decisión: Si el cifrado es obligatorio y la CPU está alta en servidor/cliente, considera servidores de archivos con AES-NI dedicados, o limita el cifrado a shares sensibles (si la política lo permite).

9) Prueba resolución de nombres y el problema de “servidor equivocado”

cr0x@server:~$ getent hosts files01
10.40.2.10  files01.corp.example files01

Significado: Confirma qué IP usará tu cliente. La deriva de DNS puede enviar clientes a un nodo retirado, a un objetivo de DR o a un balanceador que carece de comportamiento sticky para SMB.

Decisión: Si la IP es inesperada, arregla DNS primero. No toques opciones de montaje mientras hablas con el servidor equivocado.

10) Revisa retransmisiones TCP y errores de NIC en el cliente

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8123456      0     120       0  12345
    TX:  bytes packets errors dropped carrier collsns
    8765432109  7456789      0       0       0      0

Significado: Los drops pueden correlacionarse con stalls NFS/SMB. Los drops no siempre son fatales, pero drops persistentes bajo carga son un problema de fiabilidad, no una “oportunidad de tuning”.

Decisión: Si los drops suben durante incidentes, investiga tamaños de ring de NIC, congestión de switch, softirq de host y consistencia MTU extremo a extremo.

11) Mide la MTU del camino (la fragmentación silenciosa miente)

cr0x@server:~$ ping -M do -s 1472 nas01 -c 2
PING nas01 (10.20.1.50) 1472(1500) bytes of data.
1472 bytes from 10.20.1.50: icmp_seq=1 ttl=63 time=0.621 ms
1472 bytes from 10.20.1.50: icmp_seq=2 ttl=63 time=0.608 ms

--- nas01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Significado: Confirma que MTU 1500 funciona sin fragmentación. Si hay jumbo frames, prueba también esos tamaños.

Decisión: Si payloads más grandes fallan, puede haber un desajuste MTU que se manifiesta como “cuelgues aleatorios bajo carga”, especialmente para I/O grandes.

12) Prueba de velocidad rápida (lectura)

cr0x@server:~$ dd if=/mnt/fs/bigfile.bin of=/dev/null bs=8M count=64 status=progress
536870912 bytes (537 MB, 512 MiB) copied, 0.92 s, 583 MB/s
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0.92 s, 581 MB/s

Significado: Una comprobación aproximada de throughput de lectura. Si esto es rápido pero tu app es lenta, probablemente tratas con metadatos, bloqueo o patrones de I/O pequeños.

Decisión: No “arregles el almacenamiento” si la ruta de lectura secuencial está bien. Perfila metadatos y patrones de acceso de la aplicación.

13) Prueba de estrés de metadatos (latencia de listado de directorio)

cr0x@server:~$ time ls -U /mnt/fs/workdir > /dev/null

real    0m12.418s
user    0m0.012s
sys     0m0.824s

Significado: 12 segundos para enumerar un directorio indica un cuello de botella en metadatos: CPU del servidor, búsquedas de disco, demasiados archivos pequeños o comportamiento de caché de atributos.

Decisión: Si los metadatos son lentos, considera reorganizar cargas, usar espacio local temporal o escalar el rendimiento de metadatos del servidor (CPU, RAM, SSD para metadatos, mejor NAS). Ajustar rsize no te salvará.

14) Confirma opciones de montaje SMB en el cliente (y si las semánticas de caché son sensatas)

cr0x@server:~$ grep -E 'cifs|smb3' /proc/mounts
//files01/hr /mnt/hr cifs rw,relatime,vers=3.1.1,cache=strict,username=svc-linux,uid=1000,gid=1000,seal,sign,soft,nounix,serverino 0 0

Significado: Puedes ver si usas cache=strict (normalmente más seguro), dialecto SMB y banderas de seguridad como seal (cifrado).

Decisión: Si ves dialectos antiguos o modos de caché permisivos, planifica una actualización/ajuste. Si el cifrado está activo y el rendimiento es malo, mide CPU y considera cambios de política.

15) Revisa iowait y softirq de CPU (pila de red bajo presión)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server)  02/03/2026  _x86_64_  (8 CPU)

12:02:11 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:02:12 PM  all   12.3  0.0  8.1   31.7    0.0  9.8    0.0  38.1
12:02:13 PM  all   11.8  0.0  7.9   33.0    0.0  10.2   0.0  37.1

Significado: Alto %iowait puede significar esperas de almacenamiento; alto %soft sugiere carga de procesamiento de red. Ambos pueden contribuir a “cuelgues”.

Decisión: Si softirq es alto durante cifrado SMB o tráfico NFS intenso, considera escalado de CPU, ajustes RSS o offload de NIC—con cuidado y testeado.

16) Revisa latencia de disco en el servidor (si controlas el servidor)

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (nas01)  02/03/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.20   18.10    0.00   63.30

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0   180.0  8800.0  7200.0   2.1   0.4   16.0
sda              15.0    90.0   300.0  1800.0  48.7   2.5   85.0

Significado: await y %util apuntan a contención en disco. Un spindle ocupado puede arruinar el día de todos si aloja metadatos o diarios.

Decisión: Si un dispositivo está al máximo, arregla el layout de almacenamiento (mueve metadatos/diario, añade SSD, rebalancea, arregla RAID) antes de tocar banderas de protocolo.

Tres minicasos del mundo corporativo

Incidente causado por una suposición equivocada: “NFS es sin estado así que el failover es trivial”

Una empresa mediana ejecutaba artefactos de build en un export NFS respaldado por un sistema de almacenamiento en clúster. El equipo de plataforma asumió que, como NFSv3 es “sin estado”, el failover entre cabezas de almacenamiento sería transparente. Hicieron una prueba manual de failover durante la comida. Pareció bien. Declararon victoria y siguieron adelante.

Semanas después, un failover real del controlador ocurrió durante una release. Los builds empezaron a colgar. No fallaban—se colgaban. Los agentes de CI se amontonaron y el tiempo de cola explotó. El on-call vio que el export seguía montado en todas partes, así que asumió que el almacenamiento estaba “arriba” y reinició agentes. Eso solo produjo más I/O bloqueado.

El problema real: el sistema de archivos detrás del export se había movido de forma que cambió el mapeo de file handles para algunos directorios. Los clientes empezaron a lanzar errores de stale file handle para algunas rutas y reintentos indefinidos para otras. Peor aún, el sistema de build usaba muchos patrones de rename-and-stat que amplificaron las llamadas de metadatos. Los clientes quedaron haciendo reintentos y revalidaciones sin fin.

La solución fue poco glamurosa: estandarizaron en NFSv4.1 con semánticas de sesión apropiadas, habilitaron file handles estables en el lado del almacenamiento y—lo más importante—documentaron qué hace el failover a los montajes de cliente. También añadieron un job canario que ejercitaba operaciones intensivas en metadatos y alertaba si la latencia se desviaba tras failovers.

La lección: “sin estado” no significa “inmune al dolor relacionado con estado”. Tu estado de aplicación sigue existiendo, tu caché cliente existe y el servidor aún tiene que mapear handles a objetos reales.

Optimización que salió mal: “Activa cifrado SMB en todas partes; la seguridad estará feliz”

Una empresa global decidió exigir cifrado SMB3 en todos los shares, incluidos los usados para distribución masiva de software. La intención era buena: existen datos sensibles y no querían confiar eternamente en cada segmento de la red. Cambiaron la política en el lado Windows y actualizaron configuraciones Samba.

En días, hosts Linux que montaban shares con seal empezaron a reportar stalls intermitentes en horas pico. Jobs de copia que antes tardaban minutos ahora tardaban mucho más, y tareas interactivas se sentían “pegajosas”. Nada estaba caído. Todo simplemente… lo suficientemente lento como para culpar a “la red”.

Persiguieron MTU, switches e incluso arrays de almacenamiento. La pista estaba en los servidores de archivos: uso CPU alto, específicamente en rutas relacionadas con cripto, y procesamiento softirq elevado. El cifrado no solo añadió overhead; desplazó el cuello de botella de discos a CPUs. Bajo carga, el encolamiento provocó latencias cola largas, que los usuarios experimentaron como cuelgues.

El compromiso eventual fue pragmático: el cifrado siguió siendo obligatorio en shares sensibles, y opcional en shares de distribución masiva confinados a zonas de red de confianza. También actualizaron servidores de archivos a CPUs con mejor aceleración AES y ajustaron SMB multichannel donde fue apropiado.

La lección: las funciones de seguridad no son gratis. Si no mides capacidad CPU y latencia cola, puedes “asegurar” tus shares hasta volverlos inutilizables.

Práctica aburrida pero correcta que salvó el día: “Automount con timeouts sensatos y un canario”

Un equipo fintech tenía tanto NFS (home de Linux, herramientas) como SMB (shares multiplataforma). Habían sufrido montajes colgados años antes, así que trataron sistemas de archivos en red como dependencias, no como discos locales.

Usaron autofs para montajes de usuario y evitaron montar shares críticos al arranque a menos que el sistema pudiera tolerar un stall. También establecieron versiones NFS explícitas y timeouts conservadores, y luego probaron qué pasaba cuando el servidor desaparecía. La prueba no fue teórica; desconectaron rutas en un entorno de staging.

Cuando un mantenimiento real dejó fuera de servicio un nodo de almacenamiento, la mayoría de servicios se mantuvo saludable porque no bloqueaban al arrancar ni durante operaciones no relacionadas. La alerta canaria saltó: la latencia de metadatos en el share superó un umbral, y el on-call pudo ver “esto es un problema de dependencia de almacenamiento” de inmediato.

Aún tuvieron impacto en flujos que dependían del share. Pero el incidente permaneció contenido. No hubo fallos en cascada. No “reinicia todo”. Solo una caída de la dependencia y una recuperación clara.

La lección: prácticas aburridas—automounting, versiones explícitas, canarios—no parecen heroicas. Evitan que haga falta heroísmo.

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

1) Síntoma: procesos atascados en estado D, kill -9 no funciona

Causa raíz: NFS montado en modo hard (o I/O CIFS bloqueado) esperando al servidor/red. El kernel está esperando la finalización de I/O.

Solución: Restaura conectividad servidor/red. Si debes recuperar un host, desmonta de forma segura (umount) tras resolver conectividad, o usa un unmount perezoso solo como último recurso y espera consecuencias.

2) Síntoma: errores “Stale file handle” tras mantenimiento

Causa raíz: Sistema de archivos/export cambiado en el servidor (rollback, revert de snapshot, export movido, failover sin handles estables).

Solución: Remonta clientes afectados. En el servidor, asegúrate de file handles estables en failover y evita rollback en exports vivos sin un plan coordinado de remount para clientes.

3) Síntoma: montajes SMB se atascan intermitentemente, especialmente por la hora

Causa raíz: Renovación de tickets Kerberos o desincronización de relojes; reintentos de auth y reconexiones estancan operaciones.

Solución: Asegura NTP correcto. Valida configuración Kerberos y SPNs. Prefiere Kerberos con DNS y nombres de servicio correctos, no soluciones frágiles.

4) Síntoma: gran throughput secuencial, pésimo rendimiento de “ls” y “find”

Causa raíz: Cuello de botella de metadatos: demasiados archivos pequeños, CPU del servidor, discos lentos para metadatos o caché insuficiente.

Solución: Re-arquitecta la carga (bundle de artefactos, cache local), mejora la capa de metadatos (SSD), o escala CPU/RAM del servidor. Afinar protocolo rara vez soluciona una carga bound a metadatos.

5) Síntoma: share SMB lento solo cuando la política de seguridad está activada

Causa raíz: Sobrecoste de firmado/cifrado o inspección de paquetes; la CPU se convierte en cuello de botella.

Solución: Mide CPU y latencia cola. Usa hardware con aceleración cripto, habilita multichannel donde proceda y acota requisitos de cifrado según sensibilidad de datos y confianza de red.

6) Síntoma: NFS funciona desde algunas subredes pero no desde otras

Causa raíz: Restricciones de export, reglas de firewall o servicios RPC bloqueados (especialmente con locking NFSv3).

Solución: Prefiere NFSv4 (puerto bien conocido único 2049) para reducir complejidad de firewall. Alinea reglas de export con subredes reales de clientes y documenta.

7) Síntoma: acceso mixto Linux/Windows causa rarezas de “archivo bloqueado”

Causa raíz: Servir el mismo dataset vía NFS y SMB con semánticas de bloqueo/caché descoordinadas.

Solución: Evita dual-protocol en el mismo dataset vivo a menos que la plataforma de almacenamiento soporte coherencia entre protocolos y hayas probado los patrones exactos de la app.

8) Síntoma: cuelgues aleatorios bajo carga tras “habilitar jumbo frames”

Causa raíz: Desajuste MTU en algún punto del camino; paquetes grandes hundidos en el camino causan retransmisiones y stalls.

Solución: Valida MTU extremo a extremo. Usa ping -M do desde clientes a servidores. No despliegues jumbo frames de forma parcial.

Listas de verificación / plan paso a paso

Checklist de selección de protocolo (elige NFS o SMB con intención)

1. Clientes: ¿Mayormente Linux? Inclínate por NFSv4. ¿Mayormente Windows/AD? Inclínate por SMB3.
2. Modelo de permisos: ¿Necesitas fidelidad NTFS ACL y herramientas Windows? SMB. ¿Necesitas semántica POSIX primero? NFS.
3. Tolerancia a fallos: ¿Es peor que falle que que cuelgue? Considera timeouts y comportamiento de apps; no asumas que los valores por defecto son aceptables.
4. Seguridad: Si necesitas cifrado en la red, SMB3 lo tiene como característica de primera clase. NFS puede usar Kerberos o túneles, pero la complejidad operativa sube.
5. Realidad de la red: Enlaces inestables y redes que parpadean castigan semánticas stateful. Prefiere estabilidad e instrumenta la ruta.
6. Propiedad operativa: ¿Quién lo depurará a las 3 a.m.? Elige la pila que tu equipo realmente pueda operar.

Pasos para endurecer NFS en producción

1. Estandariza en NFSv4.1+ a menos que tengas una necesidad específica de v3.
2. Fija versiones y opciones de montaje para que el comportamiento no derive entre distribuciones.
3. Usa automount para shares de usuario para evitar cuelgues en arranque y reducir el radio de impacto.
4. Instrumenta retransmisiones y latencia (cliente nfsstat, métricas del servidor).
5. Planifica failovers: prueba comportamiento de stale handle; documenta procedimientos de remount; asegura file handles estables si la plataforma lo soporta.
6. Decide hard vs soft conscientemente: hard para corrección; soft solo cuando las apps toleren errores y aceptes el riesgo.

Pasos para endurecer SMB en producción

1. Requiere SMB3; desactiva dialectos legacy.
2. Decide el alcance de firmado/cifrado y verifica capacidad CPU durante picos.
3. Asegura DNS y sincronización de tiempo antes de culpar al almacenamiento.
4. Usa Kerberos correctamente si estás en AD: SPNs, nombres de servicio y hostnames consistentes importan.
5. Valida opciones de montaje cliente (cache=strict, dialecto, banderas de seguridad) y mantenlas uniformes en la flota.
6. Prueba comportamiento de oplocks/leases con tus aplicaciones si ves rarezas de bloqueo o lecturas stale.

Plan de migración (cuando cambias de protocolo)

1. Inventaría patrones de acceso: secuencial, intensivo en metadatos, dependiente de locks, ediciones multiplataforma.
2. Elige un grupo canario (unos pocos hosts, unos pocos usuarios) y define métricas de éxito (latencia p95, tasas de error, tiempos de build).
3. Ejecuta escritura dual solo si es necesario, y si lo haces, entiende riesgos de consistencia.
4. Corta en fases, mantén rollback simple (swap de alias DNS, cambios en mapas de montaje) y documenta el playbook operativo.
5. Tras el corte, elimina montajes legacy para no depurar dos sistemas para siempre.

Preguntas frecuentes

1) ¿Cuál se “cuelga” más: NFS o SMB?

Cualquiera puede. NFS con montajes hard tiende a producir el comportamiento más dramático de “pegado para siempre” porque el kernel reintentará indefinidamente por diseño. Los cuelgues SMB suelen provenir de reconnects/auth/resolución de nombres y pueden parecer intermitentes.

2) ¿Debería usar montajes soft para NFS?

A veces, pero trátalo como manejar explosivos: solo si la aplicación está diseñada para manejar errores de I/O correctamente y prefieres fallar a colgar. Para muchas cargas con escrituras intensas o sensibles a la corrección, los montajes soft pueden crear corrupción silenciosa o escrituras parciales.

3) ¿NFSv4 siempre es mejor que NFSv3?

Para la mayoría de entornos modernos, sí—especialmente por simplicidad de firewall e bloqueo integrado. Pero la statefulness de NFSv4 puede complicar la recuperación en redes inestables. Si tienes restricciones legacy, v3 aún puede ser viable con disciplina operativa estricta.

4) ¿Por qué “ls” sobre el share se siente más lento que copiar un archivo grande?

Porque las ops de metadatos son muchas rondas pequeñas: lookups, stats, checks de permisos, revalidación. Las lecturas secuenciales grandes amortizan el overhead. Si tu carga es intensiva en metadatos (árboles de build, checkouts de git, millones de archivos pequeños), necesitas diseñar para rendimiento de metadatos.

5) ¿Puedo servir el mismo directorio vía NFS y SMB?

Puedes, pero es arriesgado a menos que la plataforma de almacenamiento garantice coherencia de locking y caché entre protocolos y hayas probado patrones exactos de la app. La mayoría de las rarezas “aleatorias” cross-protocol son en realidad desajustes semánticos deterministas.

6) ¿El cifrado SMB garantiza mejor seguridad que NFS?

El cifrado SMB3 es directo y ampliamente desplegado. La seguridad en NFS suele hacerse con Kerberos (bueno) o con protecciones a nivel de red (que pueden ser suficientes si controlas la ruta). La mejor elección depende de tu pila de identidad y modelo de confianza de red, no del fanatismo por un protocolo.

7) ¿Cuál es la forma más rápida de probar si el problema es red vs disco del servidor?

Mira retransmisiones del cliente y drops de NIC, y compáralos con latencia de disco del servidor. Si las retrans aumentan y los discos están sanos, sospecha red. Si los discos muestran await/%util altos y la red está limpia, sospecha almacenamiento. Luego valida con una lectura controlada y una prueba de metadatos.

8) ¿Por qué los problemas SMB a veces se correlacionan con cambios de contraseña o políticas?

Porque SMB en entornos corporativos está muy integrado con la política de identidad. Rotación de credenciales, cambios de política Kerberos o inaccesibilidad de controladores de dominio pueden romper montajes o causar bucles de reconexión que se manifiestan como stalls.

9) ¿Cuál es la “menos mala” opción por defecto para una flota nueva Linux?

NFSv4.1+ para intercambio Linux-a-Linux, con automounting y opciones de montaje explícitas. Si tu organización es AD-first y espera comportamiento de ACLs Windows, usa SMB3 e invierte en corrección de identidad y capacidad CPU.

Conclusión: próximos pasos que puedes hacer hoy

Deja de tratar los sistemas de archivos en red como discos locales con un cable más largo. Elige el protocolo que coincida con tu modelo de identidad y mezcla de clientes, y luego diseña el modo de fallo con el que puedas vivir.

1. En un cliente afectado, ejecuta findmnt, dmesg y ps para identificar si tratas con NFS o SMB y si estás bloqueado en estado D.
2. Mide retransmisiones y drops (NFS: nfsstat; red: ip -s link) antes de tocar perillas de tuning.
3. Ejecuta una prueba de lectura y una de metadatos para determinar si estás limitado por throughput o por metadatos/bloqueos.
4. Estandariza configuraciones: fija versiones de protocolo, opciones de montaje y modos de seguridad en hosts. La deriva es como lo “aleatorio” entra en tus postmortems.
5. Haz los cuelgues observables: coloca canarios para latencia p95/p99 y tasas de error en los shares. No puedes gestionar lo que no ves, y “usuarios que se quejan” no es monitoreo.

Si haces esas cinco cosas, el próximo “cuelgue aleatorio” será una investigación acotada en lugar de una crisis existencial.