Ubuntu 24.04: CIFS extremadamente lento — las opciones de montaje que normalmente arreglan el rendimiento (caso #22)

Algunos hechos que realmente importan

El contexto no hace que los paquetes se muevan más rápido, pero evita que pruebes botones equivocados. Aquí hay algunos hechos cortos y concretos y apuntes históricos que aparecen en investigaciones reales:

1. SMB es más antiguo que tus tres últimas pilas de almacenamiento «modernas». Se remonta a los años 80; el SMB3 de hoy pertenece a la misma familia, con capas de seguridad y características de rendimiento añadidas con el tiempo.
2. El CIFS de Linux no es un juguete FUSE en espacio de usuario. El cliente moderno de Linux es un módulo del kernel (cifs.ko) con décadas de ajustes, pero hereda la semántica de SMB (metadatos conversadores, locks, ACL).
3. SMB1 está muerto por razones de rendimiento y seguridad. SMB2/3 redujeron la verbosidad y mejoraron el pipelining, pero aún puedes hacer que SMB3 sea lento activando características costosas sin querer.
4. El signing y el cifrado en SMB no son gratuitos. Añaden CPU por paquete y pueden desactivar ciertos offloads de NIC. Genial para redes hostiles. Terrible para “¿por qué esto es 200 MB/s más lento que ayer?”
5. La latencia daña a SMB más de lo que la gente espera. SMB puede pipelinear, pero las cargas de trabajo con muchos metadatos siguen siendo reguladas por los viajes de ida y vuelta. Un salto de 2 ms puede destrozar escaneos de directorios y copias de archivos pequeños.
6. Las operaciones de directorio son un deporte diferente a las lecturas en streaming. “Puedo leer un archivo grande a 900 MB/s” y “un millón de archivos diminutos toma horas” pueden ser ambos verdaderos.
7. Los valores por defecto de montaje son conservadores. Los valores por defecto en Linux tienden a preferir corrección y compatibilidad. Eso está bien—hasta que quieres rendimiento y conoces tu entorno.
8. SMB Multichannel existe, pero no es magia. Puede usar múltiples NIC/colas, pero solo si el servidor, el cliente y la pila de red están alineados (y no estás fijado a un solo flujo TCP por accidente).
9. “CIFS lento” frecuentemente es “DNS/Kerberos lento”. Retrasos de autenticación y timeouts en resolución de nombres pueden hacer que los montajes y reconexiones sean dolorosos, incluso si el rendimiento en estado estable está bien.

Una cita que sigue siendo válida en operaciones: La esperanza no es una estrategia. — General Gordon R. Sullivan.

Listado rápido de diagnóstico (encuentra el cuello de botella rápido)

Si haces solo una cosa de este artículo, haz esta secuencia. Está diseñada para detener el “bingo de opciones de montaje al azar” y en su lugar ponerle un nombre al cuello de botella.

Primero: confirma qué significa “lento”

• Lento para I/O secuencial grande? Sospecha signing/cifrado, límites de flujo TCP único, problemas de MTU, offloads de NIC, límites del servidor.
• Lento para archivos pequeños / metadatos? Sospecha latencia, política de caché de atributos, escaneo AV en el servidor, búsquedas de ACL, change notify, comportamiento de enumeración de directorios.
• Lento solo a veces? Sospecha referencias DFS, comportamiento de reconexión, roaming Wi‑Fi, congestión TCP, escaneos en segundo plano, contención en el servidor, o un firewall haciendo “inspección útil”.

Segundo: aisla red vs almacenamiento vs sobrecarga de protocolo

1. Línea base de red: ejecuta una prueba iperf3 hacia el mismo servidor (o la misma subred). Si la red no alcanza la velocidad, CIFS tampoco podrá.
2. Línea base local del servidor: si puedes, prueba el rendimiento del disco en el servidor (o al menos la carga de CPU durante transferencias SMB). Si el servidor está saturado en criptografía, has encontrado al villano.
3. Confirmación del protocolo: verifica el dialecto SMB negociado, signing, cifrado y si multichannel está en uso.

Tercero: cambia una cosa, mide, guarda evidencias

• Comienza por deshabilitar características de seguridad costosas solo si tu postura de seguridad lo permite (signing/cifrado). Si no, planifica CPU y considera AES‑NI, offloads de NIC o cores más rápidos.
• Luego ajusta caché y comportamiento de atributos según la carga (almacén de artefactos CI/CD vs hojas de cálculo compartidas vs directorios personales).
• Finalmente, aborda la forma de la carga: paralelismo, empaquetado de archivos pequeños, flags de robocopy/rsync y exclusiones de indexado/AV en el servidor.

Broma #1: Afinar el rendimiento de SMB es como hacer dieta—la mayoría de las veces la solución es “dejar de picar llamadas de metadatos por archivo”.

Primero la línea base: demuestra que es CIFS y no tu red

Ubuntu 24.04 no se despertó y decidió arruinarte el día. Está haciendo lo que pediste, con valores por defecto que son seguros pero no siempre rápidos. Antes de tocar opciones de montaje, verifica estas tres cosas básicas:

• Ruta: ¿estás montando el objetivo correcto (DFS puede enviarte a otro sitio)?
• Transporte: ¿estás en Ethernet cableada, la VLAN correcta y con la MTU adecuada?
• Servidor: ¿está saludable el servidor SMB o está silenciosamente con la CPU al máximo por signing/cifrado/AV?

Las quejas sobre el rendimiento de SMB suelen ser inter‑equipos: red dice que es almacenamiento, almacenamiento dice que es red, seguridad dice “funciona según diseño”, y el equipo de aplicaciones ya está escribiendo un hilo en Slack titulado “Linux es lento”. Tu trabajo es convertir sensaciones en métricas.

Opciones de montaje que normalmente arreglan el rendimiento

Hablemos de las opciones que repetidamente mueven la aguja en clientes Ubuntu 24.04. No “cada bandera que encontré en un foro”, sino las que abordan cuellos de botella comunes: negociación de dialecto, costo de signing/cifrado, caché y tamaño de solicitudes.

Comienza con una línea base moderna y sensata

Usa SMB3 salvo que tengas una razón heredada muy específica para no hacerlo. En Ubuntu 24.04, tu kernel y cifs-utils son lo bastante modernos para hacerlo limpiamente.

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,soft,nounix,serverino

Esto aún no es el montaje “rápido”. Es el montaje “predecible”:

• vers=3.1.1: fija el dialecto; evita rarezas por degradación.
• nounix: evita suposiciones de extensiones POSIX que pueden generar problemas de interoperabilidad.
• serverino: números de inode estables desde el servidor; ayuda a algunas herramientas y reduce sorpresas.
• soft: devuelve errores más rápido en problemas del servidor (decide con cuidado; ver sección de errores).

Victorias de rendimiento: reduce la sobrecarga por I/O (cuando esté permitido)

Si tu entorno actualmente impone signing o cifrado SMB, no rompas la política en producción porque leíste un blog. Pero aún necesitas conocer el costo, porque de lo contrario perseguirás banderas de montaje fantasma durante días.

Opción: deshabilitar signing (solo si la política lo permite)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,seal=no,sign=no,cache=none,actimeo=1

Qué hace esto: reduce CPU gastada en integridad de mensajes y/o cifrado. En algunas redes es una mala idea. En redes internas confiables a veces es aceptable con controles compensatorios (segmentación, firewall de host).

Opción: mantener seguridad, pero asegurar que la CPU no sea el límite

Si debes tener signing/cifrado, trátalo como TLS: necesitas holgura de CPU y idealmente aceleración por hardware (AES‑NI). Si una VM tiene asignación de vCPU débil o vecinos ruidosos, el rendimiento parecerá un problema de protocolo.

Cargas con muchos metadatos: opciones de caché que importan

Las semánticas de caché por defecto son cautelosas. Eso es bueno para la corrección con múltiples clientes. También puede hacer que cada build o operación de descompresión se sienta como caminar por melaza.

cache=strict vs cache=none

• cache=none: menos sorpresas; a menudo más lento para lecturas repetidas y metadatos.
• cache=strict: puede acelerar lecturas manteniendo relativa corrección, pero aún puede estar limitado por llamadas a metadatos.

actimeo (timeout de caché de atributos)

Para cargas que hacen stat() repetidamente (sistemas de build, escáneres de dependencias), aumentar la caché de atributos puede ser transformador.

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,cache=strict,actimeo=30

Compensación: estás aceptando que los atributos pueden estar obsoletos hasta por 30 segundos. Para “directorios home compartidos” esto puede ser molesto. Para “cache de artefactos mayormente de solo lectura” suele estar bien y ser rápido.

Rendimiento con archivos pequeños: no puedes escapar a las leyes de la física con opciones de montaje

SMB tiene que realizar múltiples operaciones por archivo: create/open, query info, read/write, close, update metadata. Multiplícalo por 500,000 archivos y has creado un benchmark de latencia.

Las opciones de montaje ayudan un poco (caché, menos viajes de ida y vuelta), pero las grandes mejoras a menudo son: reducir el número de archivos (empaquetarlos), aumentar el paralelismo con cuidado, o mover la carga a object storage / SSD local temporal y luego sincronizar.

Rendimiento con archivos grandes: cuidado con la trampa de flujo único

Muchas operaciones de “copiar un archivo grande” son efectivamente un solo flujo TCP. En enlaces de alta capacidad y latencia moderada, un flujo único puede subutilizar el canal a menos que el window scaling, el control de congestión y los tamaños de buffer estén bien. SMB Multichannel puede ayudar, pero solo cuando se negocia y el servidor lo soporta.

Broma #2: La transferencia SMB más rápida es la que tu equipo de seguridad no te hizo cifrar—desafortunadamente, ellos suelen notarlo.

Por qué importa la forma de la carga (archivos grandes vs pequeños)

En producción, “CIFS es lento” típicamente significa una de estas cosas:

• Lectura/escritura secuencial grande es lenta: estás pagando el impuesto de crypto/signing, estás atascado en un solo camino, o el almacenamiento del servidor está saturado.
• Archivos pequeños son lentos: la latencia y las operaciones de metadatos dominan; la caché y el escaneo en servidor importan más que el rendimiento bruto.
• Listado de directorio es lento: estás enumerando directorios enormes, golpeando el costo de ACL, o tu cliente realiza búsquedas adicionales.
• Montaje/conexión es lento: DNS, Kerberos, desfase de tiempo, o reintentos de configuración de sesión SMB.

Elige la herramienta adecuada. Si necesitas mover millones de archivos diminutos cada noche, SMB puede hacerlo, pero necesitas tratarlo como un problema de ingeniería de carga, no como un problema de línea de montaje.

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

Estos son los chequeos reales que ejecuto cuando alguien dice “CIFS es dolorosamente lento”. Cada tarea incluye un comando, salida realista y la decisión que tomas a partir de ello. Ejecútalos en orden si quieres; también funcionan a la carta.

Tarea 1: Confirma kernel y versiones de cifs-utils (estás debuggeando un objetivo que cambia)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ dpkg -l | egrep 'cifs-utils|linux-modules-extra' | head
ii  cifs-utils                    2:7.0-2ubuntu0.1   amd64  Common Internet File System utilities
ii  linux-modules-extra-6.8.0-41-generic  6.8.0-41.41 amd64  Linux kernel extra modules for version 6.8.0

Decisión: Si falta linux-modules-extra, puedes perder módulos opcionales y herramientas. Si el kernel es antiguo (no es tu caso en 24.04), actualiza antes de afinar.

Tarea 2: Verifica detalles del montaje y características SMB negociadas

cr0x@server:~$ mount | grep 'type cifs'
//fs01.corp.example/engineering on /mnt/eng type cifs (rw,relatime,vers=3.1.1,cache=strict,username=alice,uid=1000,gid=1000,soft,serverino,actimeo=1)

Decisión: Confirma que realmente estás usando SMB3.1.1, y ve cache/actimeo. Si esperabas una bandera de ajuste y no está presente, no estás probando lo que crees.

Tarea 3: Extrae ajustes de la sesión SMB desde el kernel (dialecto, signing, cifrado)

cr0x@server:~$ sudo cat /proc/fs/cifs/DebugData | sed -n '1,120p'
CIFS Version 2.48
Features: DFS,FSCACHE,STAT,SMB_DIRECT,INODE64,ACL,SMB2,SMB3,OPLOCKS,SECURITY
Active VFS Requests: 0
Servers:
1) Name: fs01.corp.example
   TCP status: connected
   Dialect: 3.1.1
   Security: signing required
   Encryption: yes
   Session User: CORP\alice
Shares:
1) \\fs01.corp.example\engineering
   Mounts: 1
   UNC: \\fs01.corp.example\engineering
   Options: rw,relatime,soft,serverino,actimeo=1,cache=strict

Decisión: Si signing es required y el cifrado está activado, espera sobrecarga de CPU. Si el rendimiento es bajo y la CPU está alta en cualquiera de los lados, probablemente hayas encontrado el limitador.

Tarea 4: Línea base de red con iperf3

cr0x@server:~$ iperf3 -c fs01.corp.example -P 4 -t 10
Connecting to host fs01.corp.example, port 5201
[SUM]   0.00-10.00  sec  9.45 GBytes  8.12 Gbits/sec  sender
[SUM]   0.00-10.00  sec  9.41 GBytes  8.08 Gbits/sec  receiver

Decisión: La red puede ~8 Gbit/s, así que una copia SMB de 100–200 Mbit/s no es “la red”. Ahora puedes dejar de discutir con el equipo de red y empezar a discutir con evidencia.

Tarea 5: Confirma estabilidad de la ruta (DNS, reverse lookups y referrals)

cr0x@server:~$ getent hosts fs01.corp.example
10.20.30.40   fs01.corp.example
cr0x@server:~$ smbclient -L fs01.corp.example -U 'CORP\alice' -m SMB3 | head
	Sharename       Type      Comment
	---------       ----      -------
	engineering     Disk
	IPC$            IPC       IPC Service (SMB Server)
SMB1 disabled -- no workgroup available

Decisión: Si la resolución de nombres es lenta o salta entre IPs, arregla eso primero. Si SMB1 está en juego, estás en tierra heredada y el rendimiento será impredecible.

Tarea 6: Mide el rendimiento real de copia para un archivo grande

cr0x@server:~$ dd if=/dev/zero of=/mnt/eng/test-10g.bin bs=16M count=640 oflag=direct status=progress
10737418240 bytes (11 GB, 10 GiB) copied, 33 s, 325 MB/s
640+0 records in
640+0 records out
10737418240 bytes copied, 33.0589 s, 325 MB/s

Decisión: Si el rendimiento de archivo grande es bajo, enfócate en signing/cifrado, multichannel, offloads de NIC, CPU del servidor y respaldo de almacenamiento. Si los archivos grandes están bien pero los pequeños son pésimos, salta a metadatos/caché y cambios de carga de trabajo.

Tarea 7: Mide el dolor de metadatos (bucle create/stat/unlink)

cr0x@server:~$ time bash -c 'd=/mnt/eng/meta-test; mkdir -p "$d"; for i in $(seq 1 20000); do echo x > "$d/f$i"; done; sync'
real	2m3.412s
user	0m8.941s
sys	0m47.228s

Decisión: Si esto toma minutos para 20k archivos pequeños, estás limitado por latencia/metadatos. Considera actimeo, exclusiones AV en el servidor, empaquetar archivos o mover el flujo fuera de SMB.

Tarea 8: Revisa saturación de CPU del cliente durante transferencias

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0-41-generic (cr0x) 	12/30/2025 	_x86_64_	(8 CPU)

12:10:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:10:02 PM  all  12.10   0.00  22.55    0.20  0.00   1.10    0.00  64.05
12:10:02 PM    3  70.00   0.00  25.00    0.00  0.00   2.00    0.00   3.00

Decisión: Un core al máximo mientras otros están ociosos a menudo significa trabajo crypto/signing por conexión, un flujo único, o una herramienta de copia de un solo hilo. Considera multichannel, paralelismo o reducir la sobrecarga de seguridad (si está permitido).

Tarea 9: Revisa velocidad/duplex y errores de la NIC (porque la realidad es cruel)

cr0x@server:~$ sudo ethtool eno1 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes
cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
  9812134321  8123123      0      12       0  112233
    TX:  bytes packets errors dropped carrier collsns
  8741123988  7012231      0       0       0       0

Decisión: Errores/caídas significan retransmisiones, que SMB interpretará como “¿por qué todo está pegajoso?”. Arregla problemas físicos/de red antes de afinar flags de protocolo.

Tarea 10: Valida MTU extremo a extremo (problemas de PMTUD parecen lentitud SMB)

cr0x@server:~$ ping -c 3 -M do -s 1472 fs01.corp.example
PING fs01.corp.example (10.20.30.40) 1472(1500) bytes of data.
1480 bytes from 10.20.30.40: icmp_seq=1 ttl=62 time=0.412 ms
1480 bytes from 10.20.30.40: icmp_seq=2 ttl=62 time=0.396 ms
1480 bytes from 10.20.30.40: icmp_seq=3 ttl=62 time=0.401 ms

--- fs01.corp.example ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.396/0.403/0.412/0.007 ms

Decisión: Si obtienes “Frag needed” o timeouts, tu situación de jumbo/PMTUD está rota. Arregla eso; SMB dejará de bloquearse.

Tarea 11: Revisa SMB multichannel y RDMA (si lo esperabas)

cr0x@server:~$ sudo grep -iE 'SMB_DIRECT|RDMA|Multi' /proc/fs/cifs/DebugData
Features: DFS,FSCACHE,STAT,SMB_DIRECT,INODE64,ACL,SMB2,SMB3,OPLOCKS,SECURITY

Decisión: Ver SMB_DIRECT en features no significa que lo estés usando. Si necesitas RDMA/Direct, verifica soporte en el servidor y que tu pila NIC/driver esté configurada. De lo contrario, asume TCP clásico.

Tarea 12: Detecta “impuesto de seguridad” alternando política en un recurso de prueba (en laboratorio)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/lab-nosign /mnt/lab \
  -o vers=3.1.1,username=alice,domain=CORP,sign=no,seal=no,cache=strict,actimeo=30
cr0x@server:~$ dd if=/dev/zero of=/mnt/lab/test-5g.bin bs=16M count=320 oflag=direct status=progress
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 9 s, 594 MB/s

Decisión: Si el rendimiento se duplica en una prueba controlada con signing/cifrado desactivados, tu “misterio” es el costo de la política. Escala con números, no con quejas: “el cifrado reduce el rendimiento en ~45% en esta clase de cliente”.

Tarea 13: Confirma que el servidor no esté limitando por configuración del recurso (ejemplo Windows desde Linux)

cr0x@server:~$ smbclient //fs01.corp.example/engineering -U 'CORP\alice' -m SMB3 -c 'get test-10g.bin /dev/null; quit'
getting file \test-10g.bin of size 10737418240 as /dev/null (312.4 MB/s) (average 312.4 MB/s)

Decisión: Si smbclient es rápido pero el montaje del kernel es lento, el problema son las opciones de montaje/caché/comportamiento del cliente. Si ambos son lentos, mira servidor/red.

Tarea 14: Inspecciona dmesg por advertencias de CIFS (reintentos silenciosos son lentos)

cr0x@server:~$ sudo dmesg -T | egrep -i 'cifs|smb3' | tail -n 12
[Mon Dec 30 12:02:11 2025] CIFS: VFS: \\fs01.corp.example has not responded in 180 seconds. Reconnecting...
[Mon Dec 30 12:02:12 2025] CIFS: VFS: cifs_reconnect: reconnect to server fs01.corp.example

Decisión: Cualquier reconexión, timeout o “servidor no responde” significa que estás depurando estabilidad primero. Afinar rendimiento en una sesión inestable es performance cosplay.

Tarea 15: Confirma sincronización de tiempo (Kerberos/rarezas de auth pueden ralentizar montajes/reconexiones)

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-30 12:12:44 UTC
           Universal time: Mon 2025-12-30 12:12:44 UTC
                 RTC time: Mon 2025-12-30 12:12:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Decisión: Si el tiempo no está sincronizado, arréglalo antes de culpar a CIFS. Kerberos y el establecimiento de sesiones seguras se comportan mal con desfase temporal.

Tres mini-historias corporativas desde el terreno

Mini-historia #1: El incidente causado por una suposición equivocada

La empresa: una SaaS mediana, servicios de archivos Windows para artefactos compartidos de ingeniería. Un equipo migró runners de build de Ubuntu 22.04 a 24.04. El primer lunes tras el despliegue, los tiempos de build se dispararon. La gente culpó al “nuevo kernel de Ubuntu” y comenzaron a fijar imágenes viejas.

La suposición equivocada fue sutil: asumieron que las características de rendimiento del recurso eran estables porque “el servidor no cambió”. Pero el servidor había recibido un cambio de endurecimiento de seguridad dos semanas antes: se activó el cifrado SMB para ese recurso únicamente. Los runners antiguos todavía alcanzaban otra ruta del recurso debido a una caché DFS obsoleta en sus configs, efectivamente evitando la ruta cifrada. Los nuevos runners resolvieron la referencia correctamente y aterrizaron en el destino cifrado.

En el papel esto era “funciona según diseño”. En realidad fue un incidente de producción: la capacidad de build cayó, las pipelines se encolaron y el on‑call tuvo que explicar por qué las “mejoras de seguridad” tenían un coste que nadie había medido.

La solución no fue una opción de montaje mágica. Fue una decisión: mantener el cifrado y provisionar más CPU en los servidores SMB (y asegurar AES‑NI en la clase de VM), o segmentar la red y permitir SMB sin cifrar en esa ruta interna con controles compensatorios. Eligieron lo primero para repos sensibles y crearon un recurso sin cifrar para caches no sensibles.

La lección: las líneas base de rendimiento deben incluir la postura de seguridad. Si no lo mides, lo “descubrirás” a las 2 a.m.

Mini-historia #2: La optimización que salió mal

Un equipo financiero tenía un clúster analítico Ubuntu montando un recurso CIFS para drops nocturnos de CSV. Alguien notó que el montaje usaba cache=none y actimeo=1, y decidió “acelerarlo” subiendo actimeo=600 y activando caching estricto en todas partes.

El rendimiento mejoró. Los escaneos de directorios se aceleraron. Todos celebraron, brevemente.

Entonces empezaron las alertas de calidad de datos. Un job downstream leyó archivos que habían sido reemplazados en el recurso, pero el cliente mantuvo atributos en caché el tiempo suficiente como para que la pipeline pensara “archivo sin cambios” y omitiera la ingestión. El cambio de caché fue correcto para rendimiento y erróneo para semántica. Al negocio no le importaba la afinación de SMB; le importaba que los informes estuvieran obsoletos.

Revirtieron y lo reemplazaron con un diseño aburrido: el sistema productor escribe en un directorio de staging, luego realiza un rename atómico hacia un directorio “ready”. Los consumidores solo leen de “ready” y usan checksums de contenido. Con ese flujo, actimeo=30 fue seguro y eficaz.

La lección: no ajustes la caché hasta entender tu modelo de corrección. SMB no es tu base de datos. Tu pipeline aún necesita reglas.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día

Una gran empresa tenía múltiples flotas Linux montando recursos Windows para perfiles de usuario y configuraciones de aplicaciones. Cada trimestre alguien se quejaba: “CIFS se volvió lento otra vez.” En lugar de hacer ajustes aleatorios, el equipo SRE tenía un hábito aburrido: un benchmark repetible y una sola página de “perfiles de montaje conocidos‑buenos”.

Mantenían dos perfiles: Interactivo (home dirs, corrección primero) y Bulk (caches mayormente de lectura, rendimiento primero). Ambos estaban codificados en gestión de configuración, con un pequeño canario que ejecutaba smbclient y una prueba con dd montado por kernel diariamente. Los resultados se graficaban junto a CPU del servidor, caídas de red y fallos de autenticación.

Cuando una actualización de firmware de almacenamiento introdujo pérdida de paquetes intermitente en un switch top‑of‑rack, las gráficas SMB bajaron antes de que los usuarios protestaran. El canario también mostró mensajes de reconexión en dmesg. La red inicialmente encogió de hombros porque “los enlaces están arriba”. Los datos fueron molesta y específicamente claros: errores en un puerto NIC, en un rack, correlacionados con reconexiones SMB y colapso de rendimiento.

Arreglaron un problema de capa física y restauraron el rendimiento sin tocar una sola opción de montaje. La práctica aburrida no fue heroica. Fue instrumentación y una línea base documentada.

La lección: la afinación más rápida de CIFS es probar que no necesitas afinación de CIFS.

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

1) Síntoma: Archivos grandes se limitan a 30–80 MB/s en 10 GbE

Causa raíz: signing/cifrado SMB requerido; cliente o servidor con CPU saturada; limitaciones de flujo TCP único.

Solución: Verifica signing/cifrado vía /proc/fs/cifs/DebugData. Si la política lo permite, prueba seal=no,sign=no en un recurso de laboratorio. Si no, añade CPU, asegura AES‑NI, considera SMB multichannel y confirma que los offloads de NIC no estén deshabilitados por política.

2) Síntoma: Millones de archivos pequeños toman una eternidad, pero archivos grandes están bien

Causa raíz: viajes de ida y vuelta de metadatos y latencia; caché de atributos demasiado estricta; escaneo AV en cada open/close.

Solución: Incrementa actimeo con cuidado (p. ej., 10–30) para cargas mayormente de lectura; empaqueta archivos pequeños en archivos; añade paralelismo; coordina exclusiones AV en el recurso para rutas seguras conocidas.

3) Síntoma: El listado de directorio es dolorosamente lento

Causa raíz: directorios enormes; costo de evaluación de ACL; cliente realizando stat adicionales; bouncing de referrals DFS.

Solución: Evita directorios planos gigantes; shardea por prefijo/fecha/proyecto. Confirma destino estable y sin sorpresas DFS. Usa caché apropiada para tus necesidades de consistencia.

4) Síntoma: Los montajes cuelgan 30–60 segundos y luego funcionan

Causa raíz: timeouts DNS, stalls en reverse lookup, reintentos Kerberos, desfase de tiempo, retardos por inspección de firewall.

Solución: Arregla resolución de nombres; verifica sincronización de tiempo; valida configuración de Kerberos; revisa logs de firewall; prefiere FQDNs estables; evita registros A múltiples a menos que sepas cómo los clientes eligen.

5) Síntoma: “Servidor no responde” y reconexiones bajo carga

Causa raíz: pérdida de paquetes, problemas MTU/PMTUD, NIC/driver defectuoso, o servidor sobrecargado alcanzando timeouts.

Solución: Revisa errores/caídas en la interfaz; confirma MTU con ping -M do; busca reconexiones CIFS en dmesg; arregla la estabilidad del transporte antes de afinar.

6) Síntoma: Después de “optimizar”, las apps ven datos obsoletos

Causa raíz: caché de atributos agresiva (actimeo) usada en un recurso sensible a corrección.

Solución: Reduce actimeo (1–5) o usa el perfil seguro; rediseña el flujo usando renames atómicos y directorios ready/staging.

7) Síntoma: Clientes Linux son más lentos que Windows para el mismo recurso

Causa raíz: diferentes características negociadas, diferentes requerimientos de signing por política del cliente, diferentes valores por defecto de caché, o ruta distinta (DFS).

Solución: Compara ajustes negociados en ambos lados. No compares un cliente Windows en la misma VLAN con una VM Linux a través de un firewall y lo llames ciencia.

8) Síntoma: El rendimiento colapsa solo en Wi‑Fi o VPN

Causa raíz: latencia y pérdida; MTU de VPN; flujo TCP único; inspección de paquetes.

Solución: Usa split tunneling si está permitido; corrige MTU; usa transferencias paralelas; considera mover operaciones masivas fuera de SMB en escenarios remotos.

Listas de verificación / plan paso a paso

Paso a paso: desde la queja hasta la solución sin adivinar

1. Clasifica la lentitud: archivo grande vs archivo pequeño vs listado de directorio vs tiempo de montaje.
2. Demuestra capacidad de red con iperf3 (streams paralelos).
3. Confirma características SMB negociadas vía /proc/fs/cifs/DebugData: dialecto, signing, cifrado.
4. Mide una transferencia controlada de archivo grande (I/O directo) para eliminar ilusiones de page cache.
5. Mide una prueba controlada de metadatos (bucle create/stat/unlink).
6. Revisa estabilidad: errores de NIC, MTU, logs de reconexión CIFS.
7. Si sospechas impuesto de seguridad: prueba en un recurso de laboratorio con signing/cifrado desactivados; cuantifica la diferencia.
8. Elige un perfil de montaje:
   • Corrección primero: cache=none o actimeo cauteloso.
   • Mayormente lectura / bulk: cache=strict,actimeo=30 (o más con garantías de flujo).
9. Aborda la forma de la carga: tar archivos pequeños, paraleliza, prepara localmente, evita directorios enormes.
10. Codifica: coloca opciones de montaje en /etc/fstab (o unidades systemd) con comentarios y un responsable.
11. Regresión‑proof: mantén un pequeño benchmark/canario y alerta sobre deltas.

Dos perfiles de montaje con los que realmente puedes vivir

Perfil A: Interactivo / corrección‑primero (home dirs, ediciones compartidas)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/homes /home \
  -o vers=3.1.1,sec=krb5,cache=none,actimeo=1,soft,serverino,uid=1000,gid=1000

Usar cuando: múltiples escritores, personas editando los mismos archivos, la corrección vence a la velocidad.

Perfil B: Bulk mayormente de lectura (cache de artefactos, datasets, media)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/artifacts /mnt/artifacts \
  -o vers=3.1.1,username=buildbot,domain=CORP,cache=strict,actimeo=30,serverino,uid=1000,gid=1000

Usar cuando: lectura intensiva, pocos escritores, toleras cierta obsolescencia de atributos.

Preguntas frecuentes

1) ¿Por qué CIFS se volvió más lento en Ubuntu 24.04 comparado con 22.04?

Por lo general no “se volvió más lento” en aislamiento. Lo que cambia son las características SMB negociadas (dialecto, signing, cifrado), el comportamiento del kernel o tu entorno (política de seguridad, DNS, ruta de red). Confirma con /proc/fs/cifs/DebugData y compara.

2) ¿Qué opción de montaje da el mayor aumento de rendimiento?

Si estás limitado por CPU debido a características de seguridad, el mayor “aumento” viene de desactivar signing/cifrado—solo si la política lo permite. Si no puedes, las siguientes mayores ganancias son asegurar CPU suficiente y usar caché apropiada (cache=strict, actimeo razonable) para cargas mayormente de lectura.

3) ¿Debo siempre poner actimeo=30?

No. Es excelente para cargas mayormente de lectura y terrible para recursos sensibles a corrección con cambios frecuentes. Trátalo como una perilla que cambia semántica, no como una mejora de velocidad gratuita.

4) ¿Aún importa afinar rsize/wsize?

Menos que antes, porque SMB2/3 y el cliente del kernel manejan tamaño dinámicamente. Aún puede importar en casos límite (appliances, middleboxes extraños), pero no es mi primera palanca en Ubuntu 24.04.

5) ¿Por qué el listado de directorio es lento aunque el throughput esté bien?

Porque listar no es trabajo de throughput; es trabajo de metadatos. Cada entrada puede requerir queries de atributos y checks ACL, y los directorios enormes amplifican la latencia. Arregla con mejor layout de directorios, caché donde sea seguro y políticas de escaneo en servidor.

6) ¿Es seguro usar soft?

Depende. soft puede hacer que I/O falle en lugar de colgarse para siempre, lo cual puede ser deseable para jobs por lotes. Para cargas tipo base de datos, errores I/O inesperados pueden ser peores que esperar. Elige con intención, no por culto.

7) ¿Debo usar sec=krb5 o usuario/contraseña?

Kerberos (sec=krb5) suele ser más limpio en entornos corporativos y evita proliferación de contraseñas, pero es más sensible a DNS y sincronización de tiempo. Si los montajes son lentos o inestables, valida NTP y tickets Kerberos.

8) ¿Puede SMB Multichannel arreglar mis problemas de velocidad?

Puedes, especialmente en enlaces rápidos donde un flujo TCP subutiliza el ancho de banda. Pero necesita soporte del servidor y configuración correcta de la red/NIC. No asumas que está habilitado; verifica y prueba.

9) ¿Por qué smbclient parece más rápido que el sistema de archivos montado?

smbclient es una ruta de cliente y carga de trabajo diferente. Si es rápido mientras el montaje es lento, mira opciones de montaje, semánticas de caché y patrones de metadatos de la aplicación (muchos stats/opens). Si ambos son lentos, mira servidor/red/política.

10) ¿Cuál es la forma más rápida de mover un millón de archivos diminutos?

No lo hagas. Empáquetalos (tar/zstd), mueve un blob grande y descomprímelo localmente. Si debes mantenerlos como archivos individuales, usa paralelismo y acepta que los metadatos dominarán. SMB no es un almacenamiento de objetos de alto rendimiento.

Conclusión: qué hacer a continuación

Cuando CIFS es dolorosamente lento en Ubuntu 24.04, la solución rara vez es “añadir flags al azar”. Haz lo disciplinado:

1. Ejecuta el listado rápido de diagnóstico. Identifica si estás limitado por throughput, metadatos o estabilidad.
2. Confirma las características SMB negociadas. Si signing/cifrado son requeridos, trátalos como un requisito de capacidad, no como un misterio.
3. Elige un perfil de montaje que coincida con la carga: corrección primero para recursos interactivos, caché para bulk read‑mostly.
4. Cambia la forma de la carga si estás moviendo archivos diminutos: empaqueta, prepara localmente, paraleliza con cuidado, evita directorios masivos.
5. Codifica las opciones de montaje y mantén un pequeño canario de benchmark para notar regresiones antes que los usuarios.

Si quieres una acción práctica: captura /proc/fs/cifs/DebugData, un resultado de iperf3 y una prueba de archivo grande con dd. Con esos tres artefactos, puedes tener una conversación adulta con red, almacenamiento y seguridad—sin adivinar.