USB: el puerto «debería funcionar» que aún no lo hace

Por qué USB aún falla en 2026 (incluso cuando «funciona»)

USB falla de maneras aburridas. Ese es el problema. Las fallas rara vez se anuncian como una NIC muerta o un sistema de archivos corrupto. USB es más como la humedad: se mete en todo y solo la notas cuando algo empieza a oler a plástico quemado.

Lo «universal» en USB es marketing, no física

No existe un solo USB. Es una reunión familiar con tres generaciones, dos esquemas de nombres y un primo que no para de hablar sobre la «compatibilidad con Thunderbolt». USB puede significar:

• Diferentes conectores: Type-A, Type-B, micro, mini, Type-C.
• Diferentes velocidades: USB 2.0 High Speed (480 Mb/s), USB 3.x SuperSpeed (5/10/20 Gb/s), USB4.
• Diferentes comportamientos de transporte: almacenamiento masivo vía BOT (Bulk-Only Transport) o UAS (USB Attached SCSI).
• Diferentes expectativas de energía: 5V heredado con corriente modesta, especificaciones Battery Charging, USB Power Delivery con negociación.

El SO intenta ocultar el desorden. A veces lo consigue. A veces oculta la evidencia que necesitabas.

Los modos de fallo más comunes de USB no son bugs de software

Si gestionas sistemas de producción, aprendes un patrón: la gente culpa a los controladores primero. Los controladores a veces tienen culpa. Pero en el mundo USB, los principales culpables son físicos y eléctricos:

• Cables malos (incluidos los «cables de carga» que omiten los pares de alta velocidad).
• Potencia marginal desde puertos, hubs, conectores frontales y docks.
• Enclosures demasiado optimistas con bridges inestables, firmware antiguo y problemas térmicos.
• Problemas de integridad de señal empeorados por tiradas largas y hubs baratos.
• Decisiones de política como autosuspend/selective suspend que son verdes en un portátil y rojas en un servidor.

USB-C lo mejoró y lo empeoró

USB-C es genuinamente una mejora ergonómica. Enchufas al revés, menos tipos de conector, y puede transportar mucho: datos, energía, modos alternativos (DisplayPort), a veces Thunderbolt. Pero «puede» no es «hará». USB-C también trajo:

• Complejidad de negociación: contratos Power Delivery, descubrimiento de modos alternos, e-markers en cables.
• Ambigüedad de puertos: dos puertos Type-C idénticos pueden tener capacidades distintas.
• Ruleta de docks: un dock estable en un portátil se convierte en generador de caos en otro.

Si tratas de mantener una carga de trabajo de almacenamiento estable, la ambigüedad no es una característica.

Broma 1: USB-C es reversible, lo cual es genial—ahora puedes enchufar el cable equivocado correctamente en el primer intento.

La fiabilidad es sobre «aburrido», no sobre «rápido»

En ops, valoramos el comportamiento predecible por encima de números pico de benchmark. Los dispositivos USB—especialmente de almacenamiento—frecuentemente anuncian un rendimiento que solo existe en ráfagas cortas hacia caché bajo condiciones térmicas ideales, conectados directamente a un buen controlador, con un cable corto certificado y un hub que no sea secretamente un pequeño sistema embebido teniendo un mal día.

Si necesitas almacenamiento confiable, trata USB como un transporte de borde, no como una infraestructura de almacenamiento central. Úsalo para ingestión, exportación, aprovisionamiento y backups offline. Si lo usas para «datos de producción siempre activos», ya estás pagando el interés por esa decisión.

Una frase para mantenerte honesto: «La esperanza no es una estrategia.» — idea parafraseada repetida en círculos de ingeniería y operaciones (la atribución varía; el punto se mantiene).

Datos interesantes e historia: las partes que olvidaste

USB no se volvió omnipresente porque fuera perfecto. Ganó porque era «suficientemente bueno», barato de implementar y respaldado por coordinación industrial seria. Algunos puntos históricos concretos que aún importan operacionalmente:

1. El «Full Speed» de USB 1.1 fue 12 Mb/s. Ese legado es por qué algunos dispositivos de baja velocidad aún se comportan como si negociaran con un módem.
2. Los 480 Mb/s de USB 2.0 son ancho de banda compartido. Conecta múltiples dispositivos a un hub y no estás «añadiendo puertos», estás compartiendo el enlace en el tiempo.
3. USB 3.0 originalmente se lanzó con puertos/cables azules como pista visual. Ayudó a los humanos, pero no lo suficiente—el cableado del panel frontal y los hubs baratos aún sabotean SuperSpeed.
4. El nombrado de USB 3.x tuvo varias rebranding (3.0 vs 3.1 Gen 1 vs 3.2 Gen 1). A tu equipo de compras no le agradará esta trivia, pero a ti sí.
5. USB-C es un conector, no una velocidad. Un puerto USB-C puede ser solo USB 2.0. Sí, todavía.
6. UAS (USB Attached SCSI) existe porque BOT es ineficiente. UAS habilita encolamiento de comandos y mejor rendimiento—hasta que el firmware de una caja lo convierte en una máquina de desconexiones.
7. Thunderbolt y USB-C se solapan pero no son lo mismo. Algunos cables «USB-C» son compatibles con Thunderbolt; muchos no. Algunos docks hablan ambos; otros fingen.
8. La energía USB evolucionó de «un poco de 5V» a contratos de potencia negociados. Por eso un dispositivo puede cargarse lento en un puerto y rápido en otro, con conectores idénticos.
9. La interferencia electromagnética es real: USB 3.x puede interferir con receptores de 2.4 GHz cuando está mal apantallado. Esto aparece como «mi ratón inalámbrico muere cuando conecto un SSD».

Fíjate en el tema: capas de compatibilidad unas sobre otras. Operacionalmente, eso no es «universal». Eso es «paz negociada».

Guía de diagnóstico rápido: encuentra el cuello de botella primero

Este es el orden de triage que ahorra horas. El objetivo no es «probar cosas», es identificar si tratas con enumeración, energía, velocidad de enlace, protocolo de almacenamiento o sistema de archivos/E/S.

Primero: ¿el dispositivo se enumera limpiamente?

• Observa los logs del kernel mientras lo conectas.
• Confirma que aparece en la topología USB.
• Confirma que aparece un dispositivo de bloque (para almacenamiento).

Si la enumeración es inestable (bucles de conectar/desconectar), detente. No hagas benchmarks. Arregla potencia/cable/hub/controlador primero.

Segundo: ¿está negociando la velocidad de enlace que crees?

• Confirma «5000M» (USB 3.x) vs «480M» (USB 2.0) en la salida del sistema.
• Elimina hubs y puertos frontales.
• Intercambia cables por otros cortos y certificados conocidos.

Si está atascado en velocidades USB 2.0, tu «disco lento» suele ser solo un enlace lento.

Tercero: ¿el cuello de botella es potencia o térmico?

• Busca reinicios bajo carga.
• Comprueba si la caja o la unidad se está calentando.
• Prefiere hubs alimentados para discos giratorios y SSDs hambrientos.

Cuarto: protocolo y ruta de controladores (UAS vs BOT)

• Determina si el dispositivo usa UAS.
• Si ves reinicios/tiempos de espera extraños, intenta forzar BOT como prueba.

Quinto: pila de almacenamiento (sistema de archivos, encolamiento, sync, caché de escritura)

• Mide el rendimiento bruto del dispositivo vs rendimiento del sistema de archivos.
• Busca amplificación de E/S pequeñas.
• Confirma el comportamiento de writeback y las opciones de montaje.

Sexto: acepta la realidad y cambia el diseño

Si tu flujo depende de velocidades sostenidas altas de escritura durante horas y lo haces a través de una caja USB barata conectada por un dock, la causa raíz es arquitectónica. Reemplaza la ruta: NVMe directo, HBA SATA, transferencia por red o un appliance dedicado.

Tareas prácticas con comandos (y qué hacer después)

Estas son tareas reales que puedes ejecutar en sistemas Linux para diagnosticar dispositivos USB y el comportamiento del almacenamiento USB. Cada una incluye: el comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Watch kernel events live durante plug/unplug

cr0x@server:~$ sudo dmesg -w
[ 8421.120341] usb 3-2: new SuperSpeed USB device number 9 using xhci_hcd
[ 8421.141002] usb 3-2: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 8421.141013] usb 3-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 8421.141020] usb 3-2: Product: USB3.0 Storage Device
[ 8421.141025] usb 3-2: Manufacturer: ASMedia
[ 8421.152901] scsi host8: uas
[ 8421.154620] scsi 8:0:0:0: Direct-Access     Samsung  Portable SSD T7   0    PQ: 0 ANSI: 6
[ 8421.156774] sd 8:0:0:0: Attached scsi generic sg3 type 0
[ 8421.158900] sd 8:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)

Qué significa: La enumeración tuvo éxito; negoció SuperSpeed; el kernel vinculó el driver UAS; apareció un dispositivo de bloque como /dev/sdc.

Decisión: Si luego ves timeouts de E/S, ya sabes que el dispositivo está en UAS. Tenlo en cuenta para Task 7 (quirks de UAS).

Task 2: Listar dispositivos USB y confirmar que es visible

cr0x@server:~$ lsusb
Bus 003 Device 009: ID 174c:55aa ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 001 Device 002: ID 8087:0026 Intel Corp. AX201 Bluetooth

Qué significa: La capa USB ve el dispositivo e identifica el chipset del bridge. Para almacenamiento, el bridge suele importar más que el SSD dentro.

Decisión: Si el bridge es un problemático conocido en tu flota, deja de fingir que esto es «un problema del disco». Es un problema de la caja.

Task 3: Inspeccionar topología, velocidad y en qué puerto/hub estás

cr0x@server:~$ lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 2: Dev 9, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M

Qué significa: Tu dispositivo está a 5000M (USB 3.x), colgando del root hub del Bus 03. El root hub soporta 10000M.

Decisión: Si esperabas 10 Gb/s y solo estás a 5, considera cable, capacidad del dispositivo o capacidad del puerto. Si ves 480M, efectivamente estás limitado a ~40 MB/s en el mejor caso.

Task 4: Confirmar el dispositivo de bloque y su transporte

cr0x@server:~$ lsblk -o NAME,MAJ:MIN,SIZE,MODEL,TRAN,SERIAL,HCTL
NAME   MAJ:MIN   SIZE MODEL              TRAN   SERIAL        HCTL
sda      8:0   476.9G INTEL SSDPEKNW512G nvme                0:0:0:0
sdc      8:32  931.5G Portable SSD T7     usb    S6WBNJ0R123  8:0:0:0

Qué significa: El dispositivo existe como sdc y el transporte es usb.

Decisión: Si no aparece aquí pero sí en lsusb, tienes un problema de binding driver/transport (o un bridge muerto que se presenta como algo que no es almacenamiento).

Task 5: Ver propiedades udev (ayuda con nombres estables)

cr0x@server:~$ udevadm info --query=property --name=/dev/sdc | sed -n '1,25p'
DEVNAME=/dev/sdc
DEVTYPE=disk
ID_BUS=usb
ID_MODEL=Portable_SSD_T7
ID_SERIAL=Samsung_Portable_SSD_T7_S6WBNJ0R123
ID_SERIAL_SHORT=S6WBNJ0R123
ID_VENDOR=Samsung
ID_PATH=pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
ID_WWN=0x5002538e40a1b2c3

Qué significa: Tienes identificadores que puedes usar para montajes predictibles: /dev/disk/by-id/... o WWN.

Decisión: Para scripts, nunca uses /dev/sdX. Usa /dev/disk/by-id/ para que la unidad equivocada no sea borrada a las 2 a.m.

Task 6: Verificar velocidad negociada desde sysfs

cr0x@server:~$ readlink -f /sys/block/sdc/device | sed 's#.*/usb#usb#'
usb3/3-2/3-2:1.0/host8/target8:0:0/8:0:0:0

cr0x@server:~$ cat /sys/bus/usb/devices/3-2/speed
5000

Qué significa: El dispositivo está funcionando a 5000 Mb/s.

Decisión: Si esto dice 480 dejas de perseguir ajustes de sistema de archivos. Arregla la capa física: puerto/cable/hub.

Task 7: Comprobar si UAS está en uso (y deshabilitarlo para pruebas)

cr0x@server:~$ lsmod | grep -E '^uas|^usb_storage'
uas                    28672  1
usb_storage            81920  1 uas

Qué significa: UAS está cargado.

Decisión: Si ves reinicios/tiempos de espera en dmesg bajo carga, prueba el modo BOT añadiendo un quirk. Esto es un paso diagnóstico, no una solución permanente.

cr0x@server:~$ echo 'options usb-storage quirks=174c:55aa:u' | sudo tee /etc/modprobe.d/usb-storage-quirks.conf
options usb-storage quirks=174c:55aa:u

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0-40-generic

Qué significa: Has configurado el kernel para tratar ese vendor:product como solo BOT (deshabilitar UAS).

Decisión: Si la estabilidad mejora dramáticamente, la implementación UAS de tu enclosure es sospechosa. Reemplaza la caja o mantén el quirk sabiendo que el rendimiento puede bajar y la encolación cambia.

Task 8: Medir throughput bruto de lectura (chequeo de cordura)

cr0x@server:~$ sudo hdparm -tT /dev/sdc
/dev/sdc:
 Timing cached reads:   32410 MB in  2.00 seconds = 16219.08 MB/sec
 Timing buffered disk reads: 1542 MB in  3.00 seconds = 513.83 MB/sec

Qué significa: Lecturas en buffer ~514 MB/s: plausible para un SSD USB 3.x, no para USB 2.0.

Decisión: Si esto es ~35 MB/s, estás efectivamente en USB 2.0 o en una ruta estrangulada. Vuelve a Tasks 3 y 6.

Task 9: Medir escrituras sostenidas sin engañarte

cr0x@server:~$ sudo fio --name=write1 --filename=/mnt/usb/testfile --size=8G --bs=1M --rw=write --direct=1 --iodepth=16 --numjobs=1
write1: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.36
write1: (groupid=0, jobs=1): err= 0: pid=19022: Wed Jan 21 10:14:03 2026
  write: IOPS=420, BW=420MiB/s (440MB/s)(8192MiB/19512msec)
    clat (usec): min=870, max=55000, avg=2375.14, stdev=901.22

Qué significa: Estás obteniendo ~420 MiB/s sostenidos sobre 8G con I/O directo. Eso es «suficientemente real» para muchas tareas.

Decisión: Si las escrituras arrancan rápido y luego colapsan tras unos GB, estás agotando caché SLC o sufriendo throttling térmico. No es un bug del kernel; es comportamiento del dispositivo. Cambia dispositivo o flujo de trabajo (ráfagas vs sostenido).

Task 10: Detectar desconexiones, reinicios y errores de enlace en logs

cr0x@server:~$ sudo journalctl -k -b | grep -E 'usb .*reset|usb .*disconnect|uas|I/O error|blk_update_request' | tail -n 20
Jan 21 10:18:44 server kernel: usb 3-2: reset SuperSpeed USB device number 9 using xhci_hcd
Jan 21 10:18:45 server kernel: sd 8:0:0:0: [sdc] tag#12 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Jan 21 10:18:45 server kernel: blk_update_request: I/O error, dev sdc, sector 12845056 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0
Jan 21 10:18:45 server kernel: usb 3-2: device descriptor read/64, error -71

Qué significa: Tienes reinicios y -71 (error de protocolo) durante carga. Esto grita integridad de señal, inestabilidad de potencia, rarezas de hub/dock o firmware malo del enclosure.

Decisión: Muévete a un puerto I/O posterior (directo a placa base), cambia el cable, quita el hub/dock. Si persiste, reemplaza el enclosure.

Task 11: Inspeccionar controlador USB y driver (xHCI importa)

cr0x@server:~$ lspci -nnk | grep -A3 -i usb
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:7ae0]
	Subsystem: Dell Device [1028:0b7a]
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

Qué significa: Estás en un controlador xHCI de Intel con el driver estándar.

Decisión: Si estás en un controlador de terceros inusual (común en tarjetas add-in), prueba con un controlador diferente. Algunas tarjetas PCIe USB baratas son básicamente generadores de números aleatorios con puertos.

Task 12: Verificar estado de autosuspend para el dispositivo

cr0x@server:~$ cat /sys/bus/usb/devices/3-2/power/control
auto

Qué significa: El kernel puede autosuspender este dispositivo.

Decisión: Para almacenamiento siempre activo, autosuspend puede causar latencias sorpresa y síntomas similares a desconexión. Prueba a ponerlo en on (sin autosuspend) para ese dispositivo.

cr0x@server:~$ echo on | sudo tee /sys/bus/usb/devices/3-2/power/control
on

Task 13: Verificar opciones de montaje y comportamiento de writeback

cr0x@server:~$ mount | grep /mnt/usb
/dev/sdc1 on /mnt/usb type ext4 (rw,relatime)

Qué significa: Estás usando ext4 con opciones por defecto-ish.

Decisión: Si usas un sistema de archivos con mucho churn de metadata (o semánticas sync que no pretendías), el rendimiento puede hundirse. Para flujos removibles, considera noatime para reducir escrituras de metadata; para bases de datos, no uses USB como almacenamiento principal.

Task 14: Confirmar soporte de discard/TRIM a través del bridge

cr0x@server:~$ lsblk --discard /dev/sdc
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdc       0B      512B       2G       2G         0

Qué significa: Discard está soportado con granularidad de 2G a través de este camino.

Decisión: Si discard no está soportado (0B), el SSD puede seguir funcionando bien, pero el rendimiento sostenido puede degradarse con el tiempo según la carga. Si dependes de rendimiento estable a largo plazo, elige un mejor enclosure/bridge.

Task 15: Identificar de forma segura el dispositivo que vas a borrar

cr0x@server:~$ sudo blkid /dev/sdc /dev/sdc1
/dev/sdc: PTUUID="3e2a9a7a" PTTYPE="gpt"
/dev/sdc1: UUID="cbd43f4c-9f56-4f33-8c1a-4f2dbf4f0a45" TYPE="ext4" PARTUUID="9a02e39e-01"

Qué significa: Tienes identificadores estables.

Decisión: En automatización, apunta por UUID/PARTUUID o por-id. Si no puedes explicar exactamente qué disco vas a borrar, no estás listo para borrarlo.

Almacenamiento USB: cajas, UAS, TRIM y la mentira del «SSD portátil»

El almacenamiento USB es una pila de traducciones. El SSD interior habla NVMe o SATA. El enclosure hace bridge a USB. El host habla UAS/BOT sobre xHCI. Luego la capa de bloque, luego el sistema de archivos, luego tu aplicación. Cualquier capa puede decidir que hoy es un gran día para ser «estándar en espíritu».

Las cajas y los chips bridge son el verdadero producto

Cuando alguien dice «este SSD USB es inestable», pregunto: «¿Qué bridge?» Porque el firmware del bridge es a menudo lo que realmente compras. Dos cajas con el mismo conector y la misma velocidad anunciada pueden comportarse de forma extremadamente diferente bajo cargas reales:

• Una maneja bien I/O encolado y nunca se reinicia.
• Otra entra en pánico bajo escrituras sostenidas, reinicia el enlace y devuelve errores de E/S que tu sistema de archivos recordará para siempre.

UAS: más rápido cuando funciona, más problemático cuando no

UAS generalmente es bueno: encolamiento de comandos SCSI, mejor concurrencia, rendimiento mejorado. Pero en el campo, UAS es también donde te encuentras con:

• Bugs de firmware del enclosure que aparecen solo bajo profundidad de cola.
• Interacciones extrañas con gestión de energía.
• Dispositivos que anuncian UAS pero se comportan como si lo hubieran probado una vez un martes.

Regla operacional: si ves reinicios frecuentes, prueba BOT como diagnóstico. Si BOT «arregla» el problema, no celebres—presupuesta mejor hardware.

TRIM/discard: a veces soportado, a veces falso, a veces costoso

Discard sobre USB depende del bridge y del protocolo. Algunos bridges lo pasan; otros no; algunos lo hacen mal. Incluso cuando está soportado, el discard online puede perjudicar el rendimiento en ciertas cargas.

Para SSDs removibles usados para transferencias secuenciales grandes, puede que nunca te importe. Para SSDs USB usados como «almacenamiento barato siempre activo», te importará cuando el rendimiento de escritura se degrade y la unidad empiece a hacer garbage collection en el peor momento posible.

Caché de escritura y pérdida de energía: USB no es un UPS

Muchos SSDs portátiles y enclosures usan cachés de escritura volátiles. Si arrancas el cable, o el hub sufre una caída de tensión, puedes perder más que el último archivo. Los sistemas de archivos sobreviven, hasta que no. Si necesitas garantías de durabilidad, usa almacenamiento diseñado para ello, o asegúrate de que tu flujo sea resiliente (checksums, escrituras atómicas, transferencias por etapas).

Energía, cables, hubs y docks: los saboteadores silenciosos

Presupuesto de potencia: tu puerto no es una toma de pared

La energía USB se negocia o se asume según el nivel de la especificación. Las cosas fallan cuando:

• Un hub alimentado por bus tiene que alimentar múltiples discos.
• Un portátil en modo de bajo consumo reduce la corriente disponible.
• El diseño interno de un dock reparte mal la energía entre puertos.
• Un disco giratorio intenta arrancar y el puerto cae de tensión.

Los síntomas de problemas de potencia suelen diagnosticarse mal como «corrupción del sistema de archivos» o «kernel inestable». Busca reinicios, desconexiones y un patrón bajo carga.

Cables: el componente más barato, la falla de mayor apalancamiento

Un cable USB puede fallar de maneras no obvias:

• Carga bien pero carece de pares SuperSpeed (o están rotos).
• Es demasiado largo o está mal apantallado para la fiabilidad de alta velocidad.
• Tiene un conector inestable que hace que se produzcan microdesconexiones.

Si haces respuesta a incidentes, acabarás desarrollando un cajón etiquetado «cables conocidos buenos». Ese cajón es tu amigo.

Broma 2: La forma más rápida de mejorar la fiabilidad USB es tirar el cable que «sabes que está bien». Protestará fallando inmediatamente en tu mano.

Hubs y docks: añadiste conveniencia, no capacidad

Los hubs multiplican puertos, no ancho de banda. También añaden otro controlador, otra ruta de potencia y, a menudo, otra capa de firmware.

Los docks son hubs más video más Power Delivery más a veces Ethernet, todo en una caja pequeña con restricciones térmicas. Son impresionantes. También son candidatos principales para fallos en casos límite que se reproducen solo cuando el proyector de la sala de conferencias está enchufado.

Postura operacional: para cualquier cosa que implique I/O de almacenamiento importante, prefiere la conexión directa al host. Usa hubs/docks para teclados, ratones y periféricos «agradables de tener». Si debes usar un hub para almacenamiento, usa un hub alimentado de un proveedor reputado y pruébalo bajo carga sostenida.

Tres microhistorias corporativas desde las trincheras USB

1) El incidente causado por una suposición errónea: «USB-C significa rápido»

Una empresa mediana estandarizó una flota de portátiles delgados y emitió SSDs portátiles USB-C para mover grandes conjuntos de datos entre entornos seguros. El flujo era simple: el ingeniero exporta datos, los hashea, los lleva a un laboratorio interno, los importa. Funcionó durante meses—hasta que dejó de hacerlo.

El incidente empezó como «las transferencias están de repente lentas». La gente culpó al proveedor del disco. Luego al SO. Alguien encontró un post en un foro sobre opciones de montaje. Todos tenían una teoría porque a todos les encanta una teoría.

La causa real: un lote de cables USB-C adquiridos como «repuestos» eran capaces de carga y sincronización pero efectivamente USB 2.0 para datos de alta velocidad. El conector encajaba. Los portátiles mostraban el mismo icono. Los usuarios asumieron que USB-C implicaba SuperSpeed. Movieron terabytes a ~35 MB/s y perdieron plazos; algunas transferencias se interrumpieron a mitad camino, produciendo conjuntos parciales y comprobaciones de integridad confusas.

Una vez que el equipo ejecutó lsusb -t y miró /sys/bus/usb/devices/.../speed, quedó obvio. La solución fue aburrida: cables certificados cortos, etiquetados, y una política que las transferencias de almacenamiento se realizan en puertos y con cables conocidos. El cambio real fue cultural: «tipo de conector» se eliminó del modelo mental; «velocidad negociada» se convirtió en el chequeo.

2) La optimización que salió mal: «Suspendamos todo»

Un grupo de TI quería mejor duración de batería en su flota de portátiles. Impusieron valores por defecto de gestión de energía agresivos, incluyendo autosuspend USB, porque en papel mejoraba benchmarks y complacía al equipo de sostenibilidad. En teoría: menos vatios, sesiones más largas, menos quejas.

Después llegó otra queja: desarrolladores que trabajaban con enclosures NVMe USB veían fallos de compilación esporádicos y caches corruptos. El almacenamiento no se corrompía permanentemente, pero el sistema de compilación trataba los errores de E/S como fatales y fallaba. Reejecuciones a veces tenían éxito, a veces no. Ese es el peor tipo de fallo: el que entrena a la gente a dejar de confiar en la automatización.

Los logs del kernel mostraron reinicios y errores de E/S correlacionados con periodos de inactividad. El dispositivo se autosuspendía, luego despertaba y hacía un amago bajo carga repentina. Algunos enclosures lo manejaban. Otros no. La variabilidad convirtió la depuración en un hobby personal, que no es lo que quieres para tiempo de ingeniería financiado por nómina.

La solución fue deshabilitar selectivamente autosuspend para dispositivos de almacenamiento USB conocidos con problemas y dejarlo activado para periféricos de bajo riesgo. La lección no fue «ahorrar energía es malo». La lección fue que tratar todos los dispositivos USB por igual es una atractiva mentira. Los dispositivos sensibles a la estabilidad (almacenamiento) obtienen políticas distintas a los tolerantes (interfaz humana).

3) La práctica aburrida pero correcta que salvó el día: nombres estables y verificación

Un equipo ejecutaba backups offline semanales a discos USB rotativos guardados en una caja fuerte. Sí, backups offline—porque el ransomware no distingue tu sincronización en la nube. El proceso era monótono: insertar disco, montar por UUID, ejecutar trabajo de backup, verificar checksums, desmontar, expulsar, etiquetar, almacenar.

Una semana, un ingeniero junior conectó dos discos a la vez: el objetivo del backup y un disco para importación archivística. Linux asignó nombres de dispositivo diferente a lo esperado. /dev/sdc no era el mismo disco físico que la semana pasada.

No pasó nada catastrófico porque los scripts nunca referenciaron /dev/sdX. Usaban /dev/disk/by-uuid/ y validaban el serial esperado vía udevadm info antes de escribir. El disco «equivocado» simplemente falló la comprobación previa y la ejecución se detuvo con un error accionable.

Ese es el tipo de aburrimiento que gana incidentes: el sistema se negó a hacer lo incorrecto rápidamente. No necesitaron heroísmos. Necesitaron guardarraíles, y los tenían.

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

Estos son los modos de fallo que veo repetidamente, especialmente en entornos mixtos laptop/servidor y montajes «temporales» que silenciosamente se vuelven permanentes.

1) «Mi SSD es lento» → el dispositivo negoció USB 2.0 → reemplazar cable/puerto, quitar hub

• Síntoma: ~30–40 MB/s máximo, sin importar qué.
• Causa raíz: El dispositivo está funcionando a 480M (USB 2.0), a menudo por cable, hub o cableado frontal.
• Solución: Revisar lsusb -t y /sys/.../speed. Mover a un puerto directo. Usar un cable SuperSpeed conocido bueno.

2) Desconexiones aleatorias bajo carga → caída de potencia o browning del hub → hub alimentado o puerto directo

• Síntoma: dmesg muestra «reset SuperSpeed USB device» y errores de E/S durante escrituras.
• Causa raíz: Potencia insuficiente y estable, especialmente con hubs/docks alimentados por bus.
• Solución: Quitar hub/dock intermedio. Usar hub alimentado o puerto directo de la placa. Evitar puertos frontales para alto consumo.

3) Funciona en un host, falla en otro → interacción controlador/firmware → probar en otro xHCI, actualizar firmware

• Síntoma: Mismo dispositivo/cable se comporta distinto entre máquinas.
• Causa raíz: Diferentes controladores USB, comportamiento de BIOS/firmware o valores por defecto de política de energía.
• Solución: Comparar lspci -nnk y versiones de kernel. Actualizar BIOS/firmware. Preferir controladores bien soportados.

4) «Es rápido 10 segundos y luego se arrastra» → agotamiento de caché SLC o throttling térmico → cambiar dispositivo/flujo

• Síntoma: Empieza a 700–900 MB/s y luego cae a 80–200 MB/s en escrituras sostenidas.
• Causa raíz: Comportamiento de caché de SSD de consumo, límites térmicos del enclosure o mala disipación.
• Solución: Ejecutar una prueba sostenida con fio. Usar unidad de gama alta, mejor enclosure o diseñar en torno a escrituras en ráfagas.

5) Corrupción de sistema de archivos tras «desconectar seguro» → caché de escritura + reinicios sorpresa → siempre desmontar y sync; evitar hubs inestables

• Síntoma: Después de desconectar, el sistema de archivos necesita reparación; a veces faltan archivos recientes.
• Causa raíz: Escritos aún en vuelo o en caché; las desconexiones no son siempre eventos limpios.
• Solución: Usar sync, desmontar y solo entonces desconectar. Abordar reinicios/power issues subyacentes.

6) Timeouts UAS y errores extraños de E/S → implementación UAS defectuosa → quirk a BOT o reemplazar enclosure

• Síntoma: Errores aparecen solo con UAS; BOT es estable.
• Causa raíz: Issues de firmware del bridge con comandos encolados.
• Solución: Aplicar un usb-storage quirks=VID:PID:u o cambiar hardware. Preferir reemplazo para uso en producción.

7) «El dock funciona hasta que se conecta el monitor» → ancho de banda compartido o bug de firmware → aislar ruta de almacenamiento

• Síntoma: El almacenamiento se vuelve inestable cuando la pantalla/ethernet está activa en el dock.
• Causa raíz: Topología interna del dock y restricciones de potencia/térmicas; a veces DP alt mode desencadena eventos de reconfiguración.
• Solución: Poner almacenamiento en un puerto directo; usar el dock solo para periféricos; actualizar firmware del dock si está disponible.

8) La automatización borra el disco equivocado → nombres de dispositivo inestables → usar by-id/by-uuid + comprobaciones previas

• Síntoma: El script apunta a /dev/sdb y arruina el día de alguien.
• Causa raíz: La asignación de nodos de dispositivo cambia entre arranques y orden de conexión.
• Solución: Usar /dev/disk/by-id o UUID. Validar modelo/serial antes de operaciones destructivas.

Listas de verificación / plan paso a paso

Checklist A: «El almacenamiento USB es lento» (en menos de 10 minutos)

1. Conecta directamente a un puerto trasero de la placa base (sin hub, sin dock).
2. Ejecuta lsusb -t y confirma la velocidad de enlace (5000M/10000M, no 480M).
3. Ejecuta cat /sys/bus/usb/devices/<bus-port>/speed para confirmar.
4. Ejecuta hdparm -t para una comprobación rápida de lectura.
5. Ejecuta fio para comportamiento sostenido de escritura (8–16G, I/O directo).
6. Si el rendimiento sigue siendo malo, prueba otro cable y otro puerto/controlador.

Checklist B: «El disco USB se desconecta bajo carga» (estabilidad primero)

1. Recopila logs: journalctl -k -b y observa dmesg -w durante la reproducción.
2. Quita hubs/docks; conecta directamente.
3. Cambia el cable por uno corto conocido y bueno.
4. Revisa autosuspend: configura power/control a on para el dispositivo.
5. Determina UAS vs BOT; si es UAS, prueba deshabilitar UAS vía quirk.
6. Si los errores persisten conectado directamente con cable conocido: reemplaza enclosure/bridge.

Checklist C: Flujo de trabajo seguro para backups USB en producción

1. Monta usando UUID/by-id, no /dev/sdX.
2. Preflight: verifica modelo/serial vía udevadm info.
3. Escribe datos usando una herramienta que pueda reanudar y verificar (rsync con checksums, o hashing a nivel de aplicación).
4. Verifica integridad (hashes o scrub del sistema de archivos cuando aplique).
5. sync, desmontar y luego desconectar físicamente.
6. Rota medios y conserva al menos una copia offline.

Checklist D: Política de estandarización que realmente reduce tickets

1. Estandariza en una lista corta de enclosures/bridges que pasen pruebas de carga sostenida.
2. Compra cables certificados al por mayor, etiquétalos y trátalos como consumibles.
3. Para flujos de alto valor, prohíbe hubs/docks en la ruta de almacenamiento a menos que hayan sido probados.
4. Documenta la velocidad de enlace esperada y cómo verificarla.
5. Establece un «puerto conocido bueno» en cada clase de dispositivo (puerto trasero vs puerto lateral, etc.).

Preguntas frecuentes (FAQ)

1) ¿Por qué mi disco USB 3 aparece como USB 2 a veces?

Porque la negociación de SuperSpeed falló y el dispositivo cayó a High Speed. Los culpables usuales son la calidad del cable, hubs, cableado frontal o conectores marginales.

2) ¿USB-C siempre es más rápido que USB-A?

No. USB-C es una forma de conector, no una garantía de velocidad. Un puerto USB-C puede ser solo USB 2.0, y un puerto USB-A puede soportar USB 3.x.

3) ¿Cuál es la forma más rápida de confirmar la velocidad negociada en Linux?

Usa lsusb -t para topología y velocidad, y cat /sys/bus/usb/devices/<id>/speed para un valor numérico directo.

4) Mi SSD portátil puntúa rápido, pero copias reales son lentas. ¿Por qué?

Los benchmarks suelen golpear patrones amigables con la caché. Las copias reales pueden incluir archivos pequeños (muchos metadatos), semántica sync o escrituras sostenidas que agotan la caché SLC y disparan throttling.

5) ¿Debo deshabilitar UAS?

No por defecto. UAS suele ser mejor. Desactívalo solo cuando tengas evidencia (reinicios/timeouts) y solo como workaround para IDs vendor:product específicos.

6) ¿Por qué los hubs USB causan desconexiones con discos?

Por entrega de potencia e integridad de señal. Los hubs alimentados por bus son especialmente frágiles con almacenamiento. Incluso los hubs alimentados varían en calidad de diseño interno.

7) ¿»Quitar de forma segura» siempre previene corrupción?

Ayuda, pero no puede arreglar inestabilidad de hardware. Si el enlace se reinicia o la energía cae, aún puedes perder escrituras en vuelo. Siempre desmonta y aborda reinicios.

8) ¿Puedo usar discos USB para bases de datos de producción?

Puedes, en el mismo sentido en que puedes conducir un centro de datos con cables de extensión: puede funcionar hasta que deje de hacerlo. Usa almacenamiento apropiado.

9) ¿Por qué el mismo dock se comporta distinto en dos portátiles?

Por diferentes controladores USB, ajustes de BIOS y valores por defecto de gestión de energía. Los docks también tienen firmware propio y topología interna que interactúa con el host.

10) ¿Cómo evito que los scripts apunten al disco USB equivocado?

Usa identificadores estables: /dev/disk/by-id o UUID/PARTUUID. Añade una comprobación previa que valide el serial/modelo esperado antes de cualquier acción destructiva.

Siguientes pasos que realmente puedes tomar

USB no está maldito. Es solo un sistema por capas que se volvió popular porque oculta la complejidad—hasta que deja de poder hacerlo. Si quieres menos sorpresas, trata USB como tratas redes: mide, valida la negociación y asume que el componente más barato (cable/hub) es el culpable hasta demostrar lo contrario.

1. Construye un kit «conocido bueno»: cables cortos certificados, un hub alimentado confiable y un modelo de enclosure que hayas sometido a estrés.
2. Adopta el orden rápido de diagnóstico: enumeración → velocidad negociada → potencia/térmica → protocolo (UAS/BOT) → sistema de archivos/E/S.
3. Para automatización, cambia todo a nombres por-id/por-uuid y añade comprobaciones previas. Es aburrido. Salva carreras.
4. Si tu carga necesita rendimiento sostenido y alta fiabilidad, deja de intentar que USB sea tu almacenamiento primario. Eso no es disciplina; es negación.

USB puede «simplemente funcionar» cuando restrinjes las variables. Tu trabajo, desgraciadamente, es restringir las variables.