Tu SSD está lento sin razón: el error del controlador de almacenamiento detrás

febrero 18, 2026 • febrero 18, 2026 • Lectura: 23 min • Views: 0

¿Te fue útil?

Compraste flash rápido. Moviste la carga de trabajo. Miraste con cariño los números de “hasta”.
Y entonces producción dijo: “Qué lindo. Haré 40 MB/s y 30 ms de latencia.”

Cuando los SSD son lentos, la gente culpa al sistema de archivos, a la app, “a la red de alguna manera” o a la fase de la luna.
A menudo el culpable real es aburrido: la ruta del controlador equivocada, el modo de encolamiento erróneo, o una capa de compatibilidad que toma el control silenciosamente.
No puedes resolver el problema con ajustes si la pila es la equivocada.

Cómo se manifiesta realmente “SSD lento” en producción

La lentitud de un SSD no suele ser un solo número. Es una personalidad. Aparece como:
latencias en la cola que derivan en timeouts de página, rendimiento promedio perfecto con bloqueos aleatorios de 200 ms,
una base de datos que “funciona bien” hasta un checkpoint, o una cola de mensajes que se convierte en un procesador por lotes accidental.

Lo aterrador: la unidad puede estar bien. El enlace PCIe puede estar bien. La NAND puede estar bien.
Pero si el SO habla con tu almacenamiento a través del controlador equivocado, del transporte equivocado o del modelo de encolamiento equivocado,
puedes acabar con un chasis de Ferrari empujado por una rueda de carrito de supermercado.

Lo que hace desagradable esta clase de problemas es lo plausibles que son las explicaciones erróneas. Los sistemas de archivos pueden ser lentos.
Las aplicaciones pueden ser lentas. Los volúmenes en la nube pueden ser lentos. Sí. Pero “ruta del controlador equivocada” es la que se oculta a plena vista,
porque las cosas siguen funcionando. Simplemente… funcionalmente deprimentes.

Datos e historia interesantes (porque el almacenamiento es rencoroso y recuerda)

NVMe no fue solo “SATA más rápido”. Fue diseñado para envíos de comandos paralelos y baja latencia con muchas colas; SATA/AHCI asumía una mentalidad de cola única.
La profundidad de cola predeterminada de AHCI es diminuta según estándares modernos. NCQ existe, pero la arquitectura se construyó pensando en discos giratorios y concurrencia modesta.
La capa de bloques multi-cola de Linux (blk-mq) fue un punto de inflexión. Ayudó a escalar la sumisión de IO entre CPUs, pero también introdujo nuevas superficies de ajuste y nuevos errores peligrosos.
Los planificadores de IO no desaparecieron—algunos simplemente se volvieron irrelevantes. Para NVMe, “none” suele ser correcto; para algunos SSD SATA detrás de HBAs, un planificador aún puede importar.
La política de caché de escritura ha peleado con administradores durante décadas. “Es más rápido” y “es seguro” son con frecuencia religiones opuestas.
TRIM/DISCARD no es gratis. El discard en línea puede crear ráfagas de latencia según el firmware del dispositivo y el comportamiento del kernel; fstrim periódico suele comportarse mejor.
Las capas de emulación SCSI están en todas partes. Muchos hipervisores y appliances de almacenamiento exponen “discos SCSI” incluso cuando el backend es SSD/NVMe; esto puede limitar el encolamiento y complicar ajustes.
Multipath puede ser una característica de rendimiento o un impuesto de rendimiento. Una sola política mal ajustada puede convertir caminos paralelos en tristeza serializada.
Las fallas en la negociación del ancho/velocidad PCIe son más comunes de lo que se admite. Un conector marginal puede “degradar” tu NVMe a un dispositivo muy caro tipo SATA.

Guía rápida de diagnóstico (primero/segundo/tercero)

No tienes tiempo para un viaje espiritual por los subsistemas del kernel. Quieres señal, rápido.
Aquí está el orden que suele atrapar los mayores errores de “SSD lento” por controlador con el menor esfuerzo.

Primero: confirma qué piensa el kernel que es el dispositivo

¿Es realmente nvme, o aparece como sdX por traducción SCSI?
¿Está detrás de RAID/HBA por hardware en un modo no intencionado?
¿Está multipath en juego sin que te des cuenta?

Segundo: confirma lo básico del enlace y del encolamiento

Anchura y velocidad del enlace PCIe (NVMe): x4 vs x1, Gen4 vs Gen1 importan.
Conteo de colas y profundidad de cola: una cola puede hacer llorar a una máquina multinúcleo.
Distribución de IRQ: una CPU manejando todas las completaciones NVMe es un clásico “por qué estamos al 20% de CPU y aún lentos?”

Tercero: mide la latencia correctamente antes de ajustar

Usa iostat -x para utilización y latencia media.
Usa nvme smart-log (NVMe) o smartctl (SATA/SAS) para pistas desde el dispositivo.
Ejecuta un trabajo controlado de fio para ver si la lentitud es específica de la carga o sistémica.

Solo después de eso tocas schedulers, nr_requests, read-ahead, flags de montaje del sistema de archivos o perillas de BD.
Si la pila de drivers es incorrecta, ajustar solo adorna el problema.

El error del controlador de almacenamiento detrás

El error viene en varias variantes, pero riman: el SO no está usando el controlador directo e intencionado para el hardware,
o está usando el controlador correcto con el modelo de colas/interrupciones equivocado debido a valores por defecto o configuración heredada.

Sabor 1: “Es NVMe” (pero presentado como SCSI)

En metal desnudo, un dispositivo NVMe real aparece como /dev/nvme0n1 y usa el driver nvme.
En muchos entornos—especialmente virtualizados y algunos appliances de almacenamiento—verás un backend rápido presentado como un disco SCSI:
/dev/sda, cadena de drivers a través de virtio-scsi, mpt3sas, device-mapper, o multipath.

A veces eso está bien. A veces limita silenciosamente el encolamiento, cambia el comportamiento de completación o introduce una cola única como cuello de botella.
El backend puede hacer 800k IOPS. Tu invitado puede enviar 30k. Todos culpan al SSD.

Sabor 2: ruta AHCI/SATA usada cuando existe una ruta NVMe

Esto ocurre con configuraciones BIOS extrañas, placas portadoras inusuales o dispositivos que pueden operar en múltiples modos.
Una unidad que debería estar en una ruta PCIe/NVMe termina siendo enrutada a través de un controlador SATA o una capa de traducción.
Funciona. También deja rendimiento sobre la mesa, especialmente bajo concurrencia.

Sabor 3: blk-mq/colas/IRQs desalineados con la topología de CPU

NVMe está diseñado para paralelismo. Linux puede hacer paralelismo. Pero aún puedes obtener:
una cola, una IRQ, una CPU, y 63 núcleos observándolo todo.
O puedes tener tormentas de interrupciones ancladas a CPU0 por ajustes legacy de irqbalance, reglas antiguas en initramfs,
o alguien que “optimizó interrupciones” en 2019 y lo olvidó.

Sabor 4: capas device-mapper haciendo más de lo que crees

LVM, dm-crypt, dm-multipath, MD RAID—estos pueden estar perfectamente bien. También pueden configurarse en una esquina:
tamaño de chunk equivocado, scheduler equivocado, política de caché de escritura equivocada, selector de rutas equivocado.
El perfil de rendimiento se vuelve “bien en benchmarks, triste en producción,” porque el IO real no es tan educado.

Aquí está la regla operacional: antes de culpar al SSD, traza la ruta de IO de extremo a extremo y confirma el controlador y el modelo de colas en cada capa.

Una idea parafraseada de W. Edwards Deming encaja dolorosamente bien con el trabajo de almacenamiento: Sin datos, solo eres otra persona con una opinión. (idea parafraseada)

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las comprobaciones que realmente ejecuto cuando un SSD está “lento”. Cada tarea incluye: un comando, lo que significa la salida y la decisión que tomas.
Ejecútalas como root cuando sea necesario.

Tarea 1: Identificar el dispositivo y el transporte (NVMe vs SCSI/SATA)

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN,MOUNTPOINTS
NAME        MODEL               SIZE ROTA TYPE TRAN MOUNTPOINTS
nvme0n1     SAMSUNG MZVL21T0HCLR 1.0T    0 disk nvme
├─nvme0n1p1                      1G    0 part nvme /boot
└─nvme0n1p2                   1023G    0 part nvme /

Significado: TRAN nvme y ROTA 0 es lo que quieres para un SSD NVMe local.
Si ves sda con TRAN sas o transporte en blanco en lo que pensabas que era NVMe, probablemente estás en una ruta traducida.

Decisión: Si el transporte no es el esperado, detén los ajustes y mapea la ruta de IO (Tareas 2–4).

Tarea 2: Ver qué driver vinculó el kernel al dispositivo

cr0x@server:~$ readlink -f /sys/block/nvme0n1/device/driver
/sys/bus/pci/drivers/nvme

Significado: Esto confirma el driver del kernel. Para dispositivos SATA verás drivers PCI relacionados con AHCI; para HBAs verás mpt3sas/megaraid_sas, etc.

Decisión: Si el driver no es el que esperabas, investiga el modo del BIOS/controlador y el cableado/backplane.

Tarea 3: Para discos SCSI, identificar el HBA/controlador virtual

cr0x@server:~$ lsscsi -t
[0:0:0:0]    disk    ATA      SAMSUNG SSD 860  3B6Q  /dev/sda
  \_ transport: sata: phy-0:0:0

Significado: Esto te dice qué stack está presentando el disco. En VMs, podrías ver virtio o un controlador SCSI del proveedor.

Decisión: Si estás en un controlador emulado legacy, cambia a virtio-blk/virtio-scsi o dispositivo NVMe virtual si es compatible.

Tarea 4: Buscar capas device-mapper (LVM, crypt, multipath)

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
NAME            TYPE FSTYPE      SIZE MOUNTPOINTS
sda             disk             1.8T
└─mpatha         mpath            1.8T
  └─vg0-lvdata    lvm  xfs        1.8T /data

Significado: mpath indica dm-multipath. Eso no es “malo”, pero es todo un motor de políticas entre tú y el SSD.

Decisión: Si multipath está presente, verifica la política de rutas y el encolamiento (Tarea 10). Si es accidental, elimínalo con cuidado.

Tarea 5: Confirmar anchura/velocidad PCIe (NVMe)

cr0x@server:~$ lspci -s 01:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 8GT/s (downgraded), Width x1 (downgraded)

Significado: El dispositivo puede hacer Gen4 x4, pero negoció Gen3 x1. Eso puede aplanar totalmente el rendimiento e inflar la latencia bajo carga.

Decisión: Reasienta la unidad, revisa el backplane, las opciones del BIOS, la calidad del riser y el firmware. No pierdas tiempo en ajustes de software hasta que esto esté solucionado.

Tarea 6: Verificar características del controlador NVMe e info del namespace

cr0x@server:~$ nvme id-ctrl /dev/nvme0 | egrep -i 'mn|fr|mdts|oacs|sqes|cqes'
mn      : SAMSUNG MZVL21T0HCLR
fr      : GXA7401Q
mdts    : 9
oacs    : 0x17
sqes    : 0x66
cqes    : 0x44

Significado: La versión de firmware importa; también límites como MDTS (tamaño máximo de transferencia de datos). Un MDTS pequeño puede limitar la eficiencia del tamaño de IO.

Decisión: Si el firmware es antiguo o problemático en tu parque, programa una ventana de actualización. Si MDTS es pequeño, vigila las cargas con IO grandes.

Tarea 7: Revisar número de colas y scheduler para un dispositivo de bloque

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Significado: Para la mayoría de NVMe, none es apropiado; se apoya en la planificación interna del dispositivo y evita sobrecarga adicional del kernel.
Para algunos dispositivos/cargas, mq-deadline puede estabilizar la latencia.

Decisión: Si estás en bfq para una carga de servidor, eso es sospechoso. Usa none o mq-deadline a menos que tengas una razón probada.

Tarea 8: Revisar límites de profundidad de cola (nr_requests, max_sectors_kb)

cr0x@server:~$ cat /sys/block/nvme0n1/queue/nr_requests
64

Significado: Esta es la profundidad de la cola de solicitudes en la capa de bloque. Muy baja puede estrangular la concurrencia; muy alta puede inflar latencia y uso de memoria.

Decisión: Si ves valores muy bajos en un dispositivo NVMe ocupado, investiga por qué (reglas udev, perfiles tuned). Cambia solo después de medir con fio.

Tarea 9: Mirar latencia en tiempo real y utilización del dispositivo

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  02/04/2026  _x86_64_ (64 CPU)

Device            r/s     w/s   rMB/s   wMB/s   await  svctm  %util
nvme0n1         1200    800     90.0   110.0    18.5   0.4   98.0

Significado: %util cercano al 100% con svctm bajo pero await alto insinúa encolamiento: el dispositivo es rápido, pero las solicitudes esperan.
Eso puede ser normal bajo carga intensa—pero también puede significar que tienes un cuello de botella de cola única aguas arriba.

Decisión: Si await es alto y el rendimiento es mediocre, profundiza en colas/IRQs y cualquier capa DM.

Tarea 10: Revisar política de dm-multipath y salud de rutas

cr0x@server:~$ multipath -ll
mpatha (3600508b400105e210000900000490000) dm-2 NETAPP,LUN
size=1.8T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Significado: La política y prioridad deciden cómo se distribuye el IO. Algunas políticas efectivamente serializan IO a una ruta salvo que estén configuradas.

Decisión: Si esperabas balanceo de carga pero ves una ruta haciendo todo el trabajo, corrige la configuración de multipath (y valida con iostat en sdb/sdc).

Tarea 11: Revisar distribución de IRQ NVMe (la prueba “CPU0 está triste”)

cr0x@server:~$ grep -i nvme /proc/interrupts | head
  45:  98234120   1023      0      0      0      0      0      0  IR-PCI-MSI 524288-edge  nvme0q0
  46:       120 98220110      0      0      0      0      0      0  IR-PCI-MSI 524289-edge  nvme0q1

Significado: Deseas que las interrupciones estén distribuidas razonablemente entre CPUs. Si todos los contadores se acumulan en una CPU, la latencia puede dispararse bajo carga.

Decisión: Si está sesgado, revisa irqbalance, afinidad de CPU y si el sistema está fijando interrupciones por ajustes antiguos.

Tarea 12: Validar comportamiento de TRIM/discard

cr0x@server:~$ findmnt -no TARGET,OPTIONS /
/ rw,relatime,discard

Significado: El discard en línea está habilitado. Eso puede estar bien, o puede crear picos de latencia según la unidad y el kernel.

Decisión: Si ves tormentas periódicas de latencia que se correlacionan con eliminaciones, considera quitar discard y usar fstrim programado.

Tarea 13: Confirmar soporte de discard y alineación

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME     DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1       512B       2T         0

Significado: La granularidad de discard y el máximo importan. Si discard no es compatible (zeros), fstrim no ayudará y la opción de montaje “discard” es inútil.

Decisión: Si no está soportado, deja de pensar que TRIM te salvará. Mira sobreaprovisionamiento, amplificación de escritura y patrones de carga.

Tarea 14: Ejecutar una prueba controlada de fio (no hagas benchmark en vivo en el volumen de la BD)

cr0x@server:~$ fio --name=randread --filename=/dev/nvme0n1 --direct=1 --ioengine=io_uring --iodepth=32 --rw=randread --bs=4k --numjobs=4 --time_based=1 --runtime=20 --group_reporting
randread: (groupid=0, jobs=4): err= 0: pid=1234: Tue Feb  4 12:00:00 2026
  read: IOPS=320k, BW=1250MiB/s (1310MB/s)(24.4GiB/20s)
  lat (usec): min=45, max=2200, avg=120.3, stdev=35.7

Significado: Esto te da IOPS y latencia de lectura aleatoria de referencia. Si esto es terrible en el dispositivo crudo, no es tu sistema de archivos.

Decisión: Si fio muestra que el dispositivo es rápido pero tu app es lenta, mira hacia arriba (sistema de archivos, caché de página, patrón de IO de la app).
Si fio también es lento, sigue investigando en el driver/colas/ruta PCIe.

Tarea 15: Revisar política de caché de escritura (SATA/SAS)

cr0x@server:~$ hdparm -W /dev/sda
/dev/sda:
 write-caching =  1 (on)

Significado: Tener caché de escritura activada puede mejorar el rendimiento pero depende de la protección frente a pérdida de energía del disco y tu tolerancia al riesgo.

Decisión: Si operas sin PLP y te importa la durabilidad, manténlo conservador. Si tienes PLP y la caché está desactivada, activarla puede ser una mejora segura.

Broma #1: El almacenamiento es el único lugar donde “está funcionando” puede significar “está arruinando silenciosamente tu trimestre.”

Tres mini-historias corporativas (anónimas, plausibles y técnicamente precisas)

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

Un equipo migró un clúster de métricas muy activo de SSD SATA antiguos a brillantes NVMe. Hicieron lo sensato:
clonaron las imágenes del SO, movieron montajes, validaron SMART, ejecutaron una prueba rápida de fio en staging. Los números se veían bien.
Entonces producción entró con el tráfico de las 9 a.m. y el sistema de alertas empezó a avisar por “latencia de disco > 50ms.”

La suposición era simple: “NVMe es NVMe.” Los servidores tenían unidades M.2, pero estaban instaladas en una placa portadora
que podía enrutar esos dispositivos como PCIe NVMe o como SATA, dependiendo de una opción del BIOS heredada
de una revisión de hardware anterior. La mitad del parque negoció PCIe; la otra mitad apareció como dispositivos SATA bajo AHCI.

El patrón de síntomas fue confuso: algunos nodos estaban bien, otros eran pésimos, y la carga estaba “balanceada uniformemente.”
El balanceador de carga hacía su trabajo. Simplemente estaba equilibrando usuarios entre dos mundos de almacenamiento diferentes.

La solución no fue un sysctl astuto. Fue una hoja de cálculo: números de serie mapeados a perfiles de BIOS, una ventana de mantenimiento,
y una regla estricta de “validar el transporte en el aprovisionamiento”. Tras el cambio, la latencia se normalizó de inmediato,
y el equipo recibió el recordatorio de que los valores por defecto del hardware no son contratos.

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

Un ingeniero preocupado por el rendimiento notó que el IO scheduler en varios hosts de bases de datos no estaba configurado de forma consistente.
Empujó un cambio mediante reglas udev para forzar mq-deadline en todas partes “para latencia predecible.”
Probó bien en un subconjunto pequeño, y el despliegue continuó.

Dos días después, la carga OLTP empezó a mostrar paradas periódicas. No lentitud constante—peor.
Cada pocos minutos, la latencia p99 se disparaba, la replicación se atrasaba, y luego todo se recuperaba.
Las métricas parecían indicar que el sistema entrenaba intervalos.

La causa raíz no fue que mq-deadline sea malo. Fue que la regla udev se aplicó a nodos device-mapper
e inconsistió con los namespaces NVMe subyacentes. Algunos volúmenes quedaron con ajustes de scheduler que se enfrentaban entre capas,
y los patrones de IO interactuaron con un comportamiento de TRIM con ráfagas en un modelo de unidad.

El rollback restauró la estabilidad. La solución duradera fue más aburrida: ajustar el scheduler solo en los dispositivos físicos,
evitar fijarlo en nodos dm-*, y validar la estrategia de discard por separado. Además: nunca “estandarices” perillas de rendimiento
sin verificar las clases de dispositivo que estás estandarizando.

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

Un servicio intensivo en almacenamiento corría en VMs con mezcla de NVMe local y volúmenes en red.
El equipo SRE tenía un ítem en la lista de despliegue que todos se burlaban: “Registrar el modelo del dispositivo de bloque, el transporte y el enlace del driver.”
Parecía papeleo. Era, objetivamente, papeleo.

Una semana, una actualización de imagen del SO host cambió el controlador de almacenamiento virtual predeterminado para un subconjunto de VMs.
Seguían arrancando. Seguían montando. Seguían pasando los checks de salud de la app.
Pero la latencia tail empeoró y el servicio empezó a descartar peticiones en pico de carga.

Debido al inventario aburrido previo, pudieron comparar “conocido bueno” vs “ahora” rápidamente:
mismo volumen, mismo hipervisor, distinto controlador y comportamiento de colas. El equipo no pasó dos días
culpando a la base de datos. Escalaron al equipo de virtualización con evidencia.

La solución fue revertir la elección del controlador, luego probar el nuevo controlador correctamente con el perfil real de carga.
El ítem de la lista de verificación sobrevivió, y quienes se burlaban callaron en silencio.

Broma #2: La forma más rápida de mejorar el rendimiento de almacenamiento es dejar de “optimizarlo” un viernes.

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

1) Síntoma: los benchmarks de NVMe son rápidos, la app sigue lenta

Causa raíz: La app está golpeando una ruta diferente (dm-crypt, sistema de archivos en red, multipath) que tu benchmark, o está limitada por patrones fsync/journaling.

Solución: Haz benchmark del dispositivo de bloque real usado por el sistema de archivos (sigue la cadena de lsblk), luego prueba con fio patrones que coincidan con fsync y profundidad de cola.

2) Síntoma: el throughput está limitado a números sospechosamente bajos, CPU mayormente inactiva

Causa raíz: El dispositivo negoció PCIe x1/baja Gen, o estás en modo AHCI/SATA, o una sola cola de envío/completación limita el paralelismo.

Solución: Revisa el estado del enlace con lspci -vv, confirma TRAN en lsblk, verifica distribución de IRQ y conteo de colas.

3) Síntoma: Alto `await`, bajo `svctm`, %util cerca de 100%

Causa raíz: Las solicitudes esperan en colas de software, a menudo porque la profundidad de cola está restringida o las interrupciones están mal ancladas.

Solución: Inspecciona /sys/block/*/queue/nr_requests, ajustes de cola NVMe y /proc/interrupts. Arregla afinidad/irqbalance primero.

4) Síntoma: picos aleatorios de latencia tras eliminaciones o compactaciones

Causa raíz: Discard/TRIM en línea causando trabajo síncrono, o GC del firmware interactuando con tu carga.

Solución: Quita la opción de montaje discard; programa fstrim. Confirma soporte de discard con lsblk -D.

5) Síntoma: dispositivo multipath más lento que una sola ruta

Causa raíz: Política multipath que no balancea, prioridades de ruta desiguales, o comportamiento de encolamiento como queue_if_no_path que causa paradas.

Solución: Valida con multipath -ll. Establece un path selector apropiado (p. ej., service-time) y verifica que ambas rutas lleven IO.

6) Síntoma: “SSD lento” solo dentro de VMs

Causa raíz: Controlador emulado, driver paravirtual equivocado, límites bajos de colas, o throttling del host.

Solución: Cambia a virtio (o NVMe virtual) y aumenta ajustes de colas donde corresponda; verifica que el invitado vea el transporte/colas esperados.

7) Síntoma: Escrituras dramáticamente más lentas que lecturas, incluso en unidades nuevas

Causa raíz: Caché de escritura deshabilitada, supuestos PLP erróneos, o unidad en estado de energía conservador; a veces un controlador RAID fuerza write-through.

Solución: Revisa política de caché (hdparm -W / herramientas del controlador), verifica estados de energía y asegúrate de usar unidades con PLP si habilitas write-back.

8) Síntoma: Rendimiento degradó tras “actualizar el kernel”

Causa raíz: Cambios de valores por defecto: selección de scheduler, comportamiento de io_uring, parámetros nvme_core, o reglas udev sobreescritas por perfiles tuned.

Solución: Difiere valores en /sys/block/*/queue, revisa tuned/udev, confirma que el driver sigue enlazado igual.

Listas de verificación / plan paso a paso

Paso a paso: diagnosticar y arreglar el enlentecimiento por driver equivocado de forma segura

Inventaria la cadena de dispositivos.
Usa lsblk y confirma si el sistema de archivos está sobre NVMe crudo, dm-crypt, LVM, md, o multipath.
Confirma el enlace del driver.
Usa readlink -f /sys/block/DEVICE/device/driver.
Si no es lo que esperas, detente e identifica por qué.
Confirma el transporte y el modelo del controlador.
Usa lsblk -o TRAN, lsscsi -t, y lspci para el controlador del dispositivo.
Valida el enlace PCIe (NVMe).
Usa lspci -vv y busca velocidad/anchura degradada.
Arregla problemas de negociación de hardware antes de ajustes de software.
Revisa colas y schedulers por defecto.
Lee /sys/block/*/queue/scheduler y nr_requests.
Evita sobreescrituras en toda la flota a menos que las clases de dispositivo sean consistentes.
Revisa la distribución de IRQ.
Usa /proc/interrupts.
Si un núcleo toma todas las completaciones, arregla afinidad y confirma el comportamiento de irqbalance.
Mide antes de tocar perillas.
Usa iostat -x y una prueba segura de fio.
Captura línea base p50/p95/p99 de latencia.
Cambia una cosa.
Cambios de ruta de driver/modo de controlador requieren ventanas de mantenimiento. Cambios de scheduler/afinidad se pueden hacer en vivo, pero valida con cuidado.
Verifica tras los cambios.
Repite pruebas fio e iostat, luego valida con SLOs de la aplicación (latencia tail, tiempo en cola, tasas de error).
Hazlo repetible.
Incorpora la validación en el aprovisionamiento: transporte, enlace del driver, enlace PCIe y ajustes de colas deben comprobarse automáticamente.

Lista operativa: qué capturar en un ticket

lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN,MOUNTPOINTS
readlink -f /sys/block/DEVICE/device/driver
lspci -vv extracto mostrando estado del enlace (NVMe)
iostat -x 1 10 durante la ventana del incidente
/proc/interrupts filtrado para interrupciones de almacenamiento
Salida de multipath si está presente: multipath -ll
Estado trim/discard: findmnt -no OPTIONS, lsblk -D

Preguntas frecuentes

1) ¿El problema de “controlador de almacenamiento equivocado” es principalmente cosa de Linux?

Linux lo hace visible porque puedes inspeccionar la pila. Pero la clase de problema existe en todas partes:
modo de controlador equivocado, capas de emulación, límites de colas y motores de políticas pueden perjudicar cualquier OS.

2) Si mi disco es `/dev/sda`, ¿significa que no es NVMe?

En metal desnudo, sí: los namespaces NVMe aparecen como /dev/nvme*. En VMs o detrás de algunos controladores, el almacenamiento rápido puede aún aparecer como discos SCSI (/dev/sd*).
La clave es identificar el transporte real y la cadena de drivers.

3) ¿Siempre debo usar el scheduler IO `none` para SSDs?

Para NVMe, none suele ser lo correcto. Para SSDs SATA o cuando tienes capas (dm-crypt, md, multipath), mq-deadline puede suavizar la latencia.
No adivines—mide con tu carga de trabajo.

4) ¿Por qué cambiar la profundidad de cola a veces empeora la latencia?

Colas más profundas pueden aumentar el throughput pero incrementar el tiempo de espera para una sola IO, especialmente bajo contención.
Si tu app cuida la latencia tail, “más cola” puede ser autolesivo.

5) ¿Es el `discard` en línea una mala práctica?

No universalmente. Depende del firmware del dispositivo, la versión del kernel y la carga. Muchos entornos de producción prefieren fstrim periódico
porque controla cuándo ocurre el trabajo de discard.

6) Mi enlace NVMe muestra “downgraded”. ¿Siempre es hardware?

Usualmente sí. Opciones del BIOS, risers defectuosos, backplanes marginales, mal asiento o problemas de energía pueden hacer que la negociación vuelva atrás.
El software no arreglará un problema de la capa física.

7) ¿Podría la encriptación (dm-crypt) ser el “error del driver”?

La encriptación no es un error, pero sí es una capa con su propio encolamiento y coste CPU. Si haces benchmark del NVMe crudo y celebras,
luego montas un volumen encriptado y te preguntas adónde fueron las IOPS, eso es un error de medición.

8) ¿Cómo sé si multipath está ayudando o perjudicando?

Si tienes rutas redundantes, multipath vale la pena. Pero valida que esté distribuyendo IO como se pretende y no serializando todo en una ruta.
Usa multipath -ll junto con iostat por ruta.

9) ¿Cuál es el “primer cambio” más seguro cuando sospecho un problema de driver/colas?

Empieza por la observación: transporte, enlace del driver, estado del enlace, distribución de IRQ, scheduler. El cambio más seguro suele ser arreglar un desequilibrio de IRQ
(afinidad/irqbalance), porque es reversible y no cambia el formato en disco.

10) ¿Puede el firmware por sí solo hacer que un SSD sea lento?

Sí—especialmente con manejo de estados de energía, comportamiento de GC y bugs en casos límite. Pero trata el firmware como parte de la pila:
no actualices al azar, y no lo ignores cuando las comprobaciones a nivel SO estén limpias.

Conclusión: próximos pasos que puedes hacer

Cuando un SSD está lento “sin razón”, asume que hay una razón—solo que aún no encontraste la capa que te está mintiendo.
El sospechoso habitual no es la NAND. Es la ruta del controlador y el modelo de colas que tu SO terminó usando, a menudo debido a valores por defecto,
configuraciones heredadas o elecciones de virtualización.

Haz esto a continuación:

En un host afectado, captura lsblk, enlace del driver y, (para NVMe) estado del enlace PCIe.
Revisa distribución de IRQ y ajustes de cola/scheduler; corrige anclajes y desajustes obvios.
Ejecuta una prueba controlada de fio en la ruta de dispositivo real que usa la app (no en la que desearías que usara).
Si el dispositivo negoció a la baja (PCIe) o se presentó a través de un modo de controlador no intencionado, programa la corrección de hardware/BIOS—no “tunes” alrededor.
Codifica las comprobaciones en el aprovisionamiento para que no debas depurar esto dos veces.