Puertos con características faltantes: cuando «está» no significa que funcione

En qué consiste realmente este problema (y por qué sigue ocurriendo)

«Portar» es una palabra sobrecargada. A veces significa «compila y pasa pruebas unitarias». A veces significa «se puede construir en nuestra distribución». A veces significa «exponemos la API, pero la implementación es un no-op». Y a veces significa «funciona si entrecierras los ojos y evitas la mitad de las funcionalidades».

En producción, un puerto con características faltantes suele ser uno de estos:

• Presencia en tiempo de compilación sin capacidad en tiempo de ejecución. El binario incluye código, pero el kernel, el sistema de archivos, el hardware o los permisos bloquean la ruta.
• Implementación parcial. La «ruta feliz» funciona, las condiciones límite no, y esas esquinas son exactamente las que golpea producción: fallos, congestión, resync, rollback.
• Desajuste en el control de características. El interruptor existe, pero activarlo no hace efecto porque falta otro prerequisito (config del kernel, opción de módulo, sysctl, firmware).
• Retroceso silencioso. El sistema declara éxito, pero vuelve a un modo más lento o menos seguro. Solo lo notas después del primer incidente —o de la primera factura.
• Deriva de versión y ABI. Un puerto coincide con los headers upstream pero no con el comportamiento upstream; lo suficiente para compilar, diferente lo bastante para romper semánticas.

Por qué sigue ocurriendo es más simple de lo que nos gustaría admitir: a menudo se financian puertos hasta «se ejecuta», no hasta «se comporta». Las pruebas se enfocan en corrección funcional, no en corrección del espacio negativo: qué sucede cuando la característica falta, está a medias o está presente-pero-incompatible.

Y la peor categoría es «documentación correcta» sin «corrección operativa». Si la página de tu característica termina en «set enable=true», felicidades: has escrito un comunicado de prensa, no una guía de operaciones.

Una verdad operativa seca: la paridad de características rara vez es binaria. Es una matriz: versión del kernel × parches de la distro × libc × sistema de archivos × firmware × modelo de seguridad × capa de orquestación × perfil de carga de trabajo. Un puerto puede «existir» en seis de esas dimensiones y faltar en la séptima. Adivina cuál encuentra producción.

Broma #1: Una característica que solo funciona en el laboratorio se llama «demo». En producción la llamamos «ensayo de incidente».

La trampa del «portado»: las afirmaciones de compatibilidad no son afirmaciones de rendimiento

Una lectura común equivocada: «Soportado» se interpreta como «rápido», «seguro» o «equivalente». Los proveedores y los equipos de plataforma internos a menudo quieren decir una promesa más estrecha: «no se bloquea inmediatamente» o «funciona con la configuración por defecto».

Para trabajo de almacenamiento y fiabilidad, eso no basta. Necesitas responder:

• ¿Preserva las semánticas de durabilidad (fsync, barriers, cache flush) ante pérdida de energía?
• ¿Maneja correctamente el modo degradado (failover multipath, reconstrucción RAID, backfill en object store)?
• ¿Mantiene los SLOs de latencia durante compactación, GC, resync y snapshots?
• ¿Expone observabilidad (contadores, tracepoints, logs) para poder demostrar que funciona?

Si no puedes demostrarlo bajo estrés, no tienes una característica. Tienes una opinión.

Algunos hechos y contexto histórico que conviene recordar

Esto no es trivia por trivia. Explica por qué «está» tantas veces significa «no realmente».

1. La compatibilidad POSIX siempre ha sido un espectro. Diferentes sabores de UNIX históricamente «soportaron POSIX» mientras divergían en casos límite como señales, semánticas de I/O y bloqueo de archivos.
2. Las implementaciones de NFS en Linux evolucionaron de forma desigual entre versiones. Características como delegaciones de NFSv4 y idmapping pasaron largos periodos en los que existían pero eran frágiles operativamente, especialmente entre versiones mixtas cliente/servidor.
3. Las opciones de journaling de EXT4 se convirtieron en un campo minado de compatibilidad. Modos como data=ordered, barriers y comportamiento de writeback cambiaron con mejoras del kernel y correcciones al flush de caché del dispositivo.
4. Las historias de multipath NVMe y SCSI son diferentes. dm-multipath fue creado para comportamiento de la era SCSI; NVMe introdujo ANA y semánticas nativas de multipath, y «tiene multipath» no significa que falle como esperas.
5. Las banderas de características de ZFS se diseñaron para evitar trampas al actualizar pools. Es un buen sistema, pero significa que «ZFS está disponible» aún no garantiza «este pool es compatible en todos los hosts donde planeas importarlo».
6. Los contenedores volvieron a hacer visibles las semánticas de sistemas de archivos. Overlay y mounts en unión sacan a la luz comportamientos límite (rename, xattrs, whiteouts) que muchas aplicaciones nunca probaron fuera del CI.
7. glibc vs musl no es solo tamaño y licencias. Diferencias en resolución DNS, valores por defecto de stack de hilos, locale y códigos de error pueden cambiar el comportamiento en tiempo de ejecución sin cambiar tu código.
8. Las pilas criptográficas tienen larga tradición de «compila bien, falla raro». Entre versiones de OpenSSL, proveedores, modos FIPS y crypto del kernel, algoritmos pueden aparecer presentes pero estar deshabilitados por política o faltar aceleración.
9. Las offloads de red han salido con fallos más de una vez. TSO/GSO/GRO, checksum offload y segmentación pueden ser «soportados» por una NIC pero defectuosos en una combinación concreta de driver+firmware.

Modos de fallo: cómo fallan las características «portadas» en sistemas reales

1) La configuración no-op: bandera activada, nada cambia

Este es el clásico: existe una opción de configuración porque upstream la tiene, y tu port mantuvo el esquema de configuración. Pero el módulo subyacente no fue compilado con la dependencia requerida, o el entorno de ejecución lo bloquea.

Ejemplos: habilitar TRIM/discard en una VM donde el hipervisor no lo transmite; habilitar I/O asíncrono en una combinación libc/kernel donde el código silenciosamente usa I/O síncrono; habilitar «encriptación» donde solo existe la gestión de claves pero la capa de cifrado está ausente o deshabilitada por política.

2) «Soportado» pero solo en una ruta de código

Los puertos suelen implementar el caso común y saltarse las partes feas: recuperación, manejo de errores y concurrencia. Parece bien hasta que sufres una tormenta de reintentos, una elección de líder o un disco que devuelve errores medios.

3) Característica presente, semántica distinta

Este es peligroso porque no verás un fallo obvio. Obtienes resultados sutilmente incorrectos: garantías de orden distinto, comportamiento de fsync distinto, timeouts distintos, bloqueo distinto.

En términos de almacenamiento, las semánticas importan más que la velocidad. Un sistema de archivos rápido que miente sobre durabilidad no es «rápido». Es simplemente «optimista silencioso».

4) Retroceso silencioso a «modo compatibilidad»

Algunos sistemas intentan una característica, fallan en negociar y siguen adelante. Eso es amable para el usuario—hasta que se convierte en un problema de SLO. Tu app sigue funcionando, pero ahora estás con un algoritmo más lento, una versión de protocolo anterior o un modo más costoso y seguro.

5) Brecha de observabilidad: no puedes probar que funciona

Los puertos a veces omiten tracepoints, contadores o logs estructurados. La característica puede funcionar, pero no puedes confirmarlo. Cuando algo falla, no tienes migas de diagnóstico. Eso es funcionalmente equivalente a «no soportado», porque no puedes operarlo.

6) Acantilados de rendimiento con cargas reales

El puerto puede pasar pruebas de corrección e incluso benchmarks básicos, y luego caer en picado con patrones de I/O realistas: escrituras aleatorias pequeñas, lecturas/escrituras mixtas, cargas pesadas de metadata, escrituras síncronas explosivas o snapshots concurrentes.

Hay una idea parafraseada a menudo atribuida a W. Edwards Deming: Sin datos, eres solo otra persona con una opinión. En términos de ops: sin medida, eres otra persona con un pager.

Broma #2: El sistema de almacenamiento más rápido es el que descarta escrituras. También es el que recordarán tus auditores.

Guion de diagnóstico rápido: encuentra el cuello de botella antes de discutir

Cuando una «característica ported» no se comporta, la gente inmediatamente debate arquitectura. No lo hagas. Primero, establece la realidad en tres pases: negociar, observar y validar.

Primero: prueba la negociación (¿la característica está realmente habilitada de extremo a extremo?)

• Revisa las banderas en tiempo de ejecución (no los archivos de configuración): sysfs, procfs, información del driver, opciones de montaje del sistema de archivos.
• Revisa conjuntos de capacidades versionadas: banderas de características de ZFS, versiones de protocolo NFS, listas de cifrados TLS, opciones de configuración del kernel.
• Revisa el «otro lado»: servidor vs cliente, hipervisor vs guest, controlador vs iniciador.

Segundo: observa el comportamiento (¿está tomando la ruta de código prevista?)

• Usa contadores y trazas: iostat, perf, bpftrace, zpool iostat, nfsstat, estadísticas de ethtool.
• Busca evidencia de fallback: mensajes en logs, degradaciones negociadas de protocolo, banners de «usando modo seguro», advertencias en dmesg del kernel.
• Mide la distribución de latencias: p95/p99 te cuentan sobre acantilados; la media los oculta.

Tercero: valida semánticas (¿hace lo que pensabas que hacía?)

• Pruebas de durabilidad: simular pérdida de energía y validar comportamiento de fsync es difícil, pero al menos puedes validar comandos de flush, barriers y políticas de caché.
• Pruebas de modos de fallo: desconecta una ruta, mata un nodo, corrompe un bloque, llena el disco. Si el puerto no se comporta bajo estrés, no se comporta.
• Pruebas de compatibilidad: exportar/importar pools, montar desde clientes mixtos, subir/bajar versiones de componentes.

Si haces estos tres pases, dejarás de discutir sobre sentimientos y comenzarás a tomar decisiones con evidencia: «este puerto carece de la característica X en el kernel Y», o «la característica se negocia pero cae en fallback bajo carga», o «las semánticas difieren; debemos limitarla por carga de trabajo».

Tareas prácticas: más de 12 comandos que te dicen qué se soporta realmente

Estos son los tipos de comprobaciones que puedes ejecutar durante un incidente, durante una migración o antes de permitir que una plataforma «portada» toque datos de clientes. Cada tarea incluye qué significa la salida y la decisión que impulsa.

Task 1: Identify the real kernel and build flavor

cr0x@server:~$ uname -a
Linux server 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-01-23) x86_64 GNU/Linux

Qué significa: La versión del kernel y el build de la distro importan porque los puertos a menudo apuntan a «Linux» en general pero dependen de backports o configuraciones específicas.

Decisión: Si la característica depende de un rango de kernels específico, deja de adivinar. Fija el kernel o muévete a un build conocido y probado.

Task 2: Check kernel config for a supposedly “supported” feature

cr0x@server:~$ zgrep -E 'DM_MULTIPATH|NVME_MULTIPATH|BTRFS_FS|OVERLAY_FS' /proc/config.gz
CONFIG_DM_MULTIPATH=m
CONFIG_NVME_MULTIPATH=y
CONFIG_BTRFS_FS=m
CONFIG_OVERLAY_FS=y

Qué significa: El kernel solo puede ofrecer aquello para lo que fue compilado. «Soportado por la distro» a veces significa «módulo opcional que no instalaste».

Decisión: Si falta una opción requerida, no sirve de nada afinar el espacio de usuario. Arregla primero el kernel/módulos.

Task 3: Confirm module presence and parameters (runtime, not theory)

cr0x@server:~$ lsmod | egrep 'nvme|dm_multipath|zfs|overlay'
nvme_fabrics           24576  0
nvme_core             200704  2 nvme_fabrics,nvme
overlay               155648  2

Qué significa: Si el módulo no está cargado, la característica no está activa. Sencillo. Brutal.

Decisión: Carga el módulo y valida el comportamiento. Si no carga, captura dmesg y deja de afirmar que la característica existe.

Task 4: Verify filesystem mount options and actual filesystem type

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/lib/postgresql
/dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro,data=ordered

Qué significa: Muchas «características» son opciones de montaje (barriers, discard, noatime) y pueden faltar o ser sobrescritas.

Decisión: Si la opción esperada falta (por ejemplo, discard), actívala explícitamente o ejecuta trim periódico—no asumas que ocurre.

Task 5: Check whether discard/TRIM is actually supported by the block device

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

Qué significa: Si DISC-MAX es 0B, discard no está soportado a través de esta pila. Eso puede ocurrir con algunos controladores RAID, hipervisores o dispositivos mal configurados.

Decisión: No habilites opciones de discard que no hacen nada; pueden añadir overhead o dar falsa confianza. Usa una ruta de almacenamiento que propague discard si lo necesitas.

Task 6: Confirm write cache and flush behavior exposure

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

Qué significa: Tener write cache activado no es intrínsecamente malo, pero cambia tu historia de durabilidad. La pregunta importante es si los flush se respetan hasta abajo.

Decisión: Si no puedes garantizar protección de caché adecuada (BBU, PLP), debes tratar las semánticas de fsync como dudosas y ajustar tu diseño de almacenamiento.

Task 7: Measure I/O latency and saturation quickly

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0-18-amd64 (server) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.21    0.00    1.10    8.42    0.00   87.27

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
nvme0n1        120.0   980.0  4800.0 64000.0     0.0     0.0   92.1   14.3

Qué significa: Un alto %util y await en ascenso indican saturación del dispositivo o encolamiento. Si tu «característica ported» debía reducir latencia, no lo está haciendo.

Decisión: Si el dispositivo está saturado, deja de culpar a la aplicación. Arregla la ruta de I/O, la profundidad de cola, el scheduler o el aprovisionamiento.

Task 8: Confirm I/O scheduler and queue settings (common port mismatch)

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

Qué significa: Algunos schedulers funcionan mejor para ciertas cargas; algunas guías de tuning «portadas» asumen un scheduler que no está en uso.

Decisión: Si tu carga es sensible a latencia y estás en un scheduler inadecuado, prueba cambios—pero regístralos y géalos por clase de dispositivo.

Task 9: Check negotiated TLS capabilities (crypto ports love silent downgrades)

cr0x@server:~$ openssl version -a
OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023)
built on: Tue Oct 10 10:10:10 2023 UTC
platform: debian-amd64

Qué significa: Las versiones principales de OpenSSL cambian el comportamiento de proveedores. Algo «soportado» en 1.1.1 puede requerir configuración en 3.x.

Decisión: Si el comportamiento criptográfico difiere entre entornos, trátalo como riesgo de port. Valida cifrados y protocolos negociados, no asumas.

Task 10: Verify NFS protocol and client/server capabilities

cr0x@server:~$ nfsstat -m
/var/lib/app from nfs01:/export/app
 Flags: rw,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.10

Qué significa: Puedes ver la versión negociada de NFS. Si creías que estabas en 4.2 con ciertas semánticas y estás en 4.1, tu «característica» puede no existir.

Decisión: Fuerza la versión deseada y prueba. Si el servidor no puede hacerlo, deja de esperar magia en el cliente.

Task 11: Validate NVMe multipath and ANA state

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:2f2a...
\
 +- nvme0 fc traddr=nn-0x500a098... host_traddr=nn-0x500a098... live optimized
 +- nvme1 fc traddr=nn-0x500a098... host_traddr=nn-0x500a098... live non-optimized

Qué significa: Multipath «existe» solo si las rutas son visibles y los estados tienen sentido. Rutas «non-optimized» pueden ser standby o usarse incorrectamente según la política.

Decisión: Si las rutas no están presentes o los estados son erróneos, arregla zoning de la infraestructura, la configuración del host o los ajustes de multipath del kernel antes de afinar aplicaciones.

Task 12: Catch silent filesystem fallbacks in container storage

cr0x@server:~$ docker info | sed -n '/Storage Driver/,$p' | head -n 8
 Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
 userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd

Qué significa: El comportamiento de overlay depende de las características del filesystem de respaldo. Si falta soporte de d_type, overlay puede comportarse mal. Si userxattr es false, ciertas características de seguridad/metadata pueden no estar disponibles.

Decisión: Si características críticas de overlay no están soportadas, mueve el runtime a un filesystem que las soporte, o cambia el driver de almacenamiento y acepta las compensaciones.

Task 13: ZFS pool feature flags and compatibility reality

cr0x@server:~$ zpool get -H -o name,property,value ashift,autotrim,feature@async_destroy rpool
rpool	ashift	12
rpool	autotrim	off
rpool	feature@async_destroy	active

Qué significa: Las banderas de características de ZFS son explícitas. Un pool puede importarse pero aún tener características activas que puertos antiguos no pueden manejar de forma segura.

Decisión: Si necesitas portabilidad entre hosts, controla actualizaciones de pool y activación de características. «Se importa» no es lo mismo que «es seguro en todas partes».

Task 14: Check for runtime warnings that indicate stubs or disabled paths

cr0x@server:~$ dmesg -T | egrep -i 'fallback|disable|unsupported|unknown|deprecated' | tail -n 10
[Wed Jan 22 00:12:44 2026] nvme nvme0: missing or invalid ANA log, disabling ANA support
[Wed Jan 22 00:12:45 2026] overlayfs: upper fs does not support xattr, falling back to index=off

Qué significa: A veces el kernel te dice directamente que deshabilitó la característica. La gente lo ignora porque es «solo una advertencia».

Decisión: Trata estas líneas como requisitos. Si la característica está deshabilitada, deja de diseñar en torno a ella.

Task 15: Confirm syscalls and behavior differences (glibc/musl, seccomp)

cr0x@server:~$ strace -f -e trace=io_uring_setup,openat,fsync -o /tmp/trace.log ./app --once
cr0x@server:~$ tail -n 6 /tmp/trace.log
12345 io_uring_setup(256, {flags=0, sq_thread_cpu=0, sq_thread_idle=0}) = -1 EPERM (Operation not permitted)
12345 openat(AT_FDCWD, "/var/lib/app/data", O_RDONLY|O_CLOEXEC) = 3
12345 fsync(3) = 0

Qué significa: Tu app «soporta io_uring», pero en un contenedor con seccomp o privilegios insuficientes puede bloquearse y caer silenciosamente a I/O anterior.

Decisión: Si la syscall prevista está denegada, o ajusta la política del sandbox (con cuidado) o acepta el fallback y dimensiona la capacidad en consecuencia.

Tres micro-historias del mundo corporativo (anónimas, dolorosamente reales)

Mini-story 1: The incident caused by a wrong assumption

Un equipo de plataforma desplegó una nueva imagen base «hardening» para servicios internos. Se presentó como reemplazo drop-in: mismos paquetes, kernel ligeramente más nuevo, menor superficie de ataque. El plan de migración era limpio: bakear AMIs, despliegue rolling, vigilar dashboards.

Un servicio—una API con muchas escrituras y con una cola local—empezó a mostrar picos periódicos de latencia que parecían pausas de GC. CPU bien. Memoria bien. Red bien. Y sin embargo cada pocos minutos el p99 subía y el throughput caía. Todos miraban trazas de la aplicación porque, claro, debía ser la app.

No lo era. La imagen base cambió la pila de almacenamiento de forma sutil: las opciones de montaje ya no incluían discard, y el disco virtual subyacente de hecho no anunciaba discard. La imagen antigua ejecutaba un trabajo semanal de trim; la nueva no. Con el tiempo, el almacenamiento basado en SSD empezó a comportarse como un historiador pesimista: recordaba cada escritura y te lo recriminaba.

La «característica ported» fue la promesa de que la nueva imagen era operativamente equivalente. Lo era. Excepto por un comportamiento de mantenimiento aburrido que no había sido documentado como requisito, y por ende no se probó. La solución no fue heroica: restaurar el trim, validar soporte de discard end-to-end y añadir una comprobación explícita en la pipeline de imágenes para fallar builds cuando las suposiciones de almacenamiento cambien.

Mini-story 2: The optimization that backfired

Un equipo de almacenamiento migró una flota de LUNs iSCSI a NVMe over Fabrics. La demo del proveedor fue excelente. Latencia mejoró en pruebas controladas. Alguien notó que el kernel tenía soporte nativo de multipath NVMe y decidió remover dm-multipath para «reducir overhead». Stack más limpio, menos piezas móviles.

En semanas aparecieron errores intermitentes durante eventos de mantenimiento de la fibra. Nada catastrófico—solo breves stalls que causaban timeouts aguas arriba. La carga era una base de datos distribuida. Las bases de datos distribuidas son emocionalmente sensibles. Unos segundos de incertidumbre en I/O se convierten en cascadas de cambios de líder, reintentos y compactions. Todo parecía un problema de la app porque la app era la que gritaba.

La causa raíz fue asumir paridad de características: el multipath NVMe del kernel existía, pero la combinación específica de firmware y comportamiento de la fibra producía transiciones de estado ANA que el puerto no manejaba bien. El sistema mantenía rutas «live» pero clasificaba mal optimized vs non-optimized durante ciertos eventos. No estaba roto todo el tiempo, solo lo suficiente como para envenenar la latencia de cola.

La solución fue dejar de optimizar para la elegancia y optimizar para la predictibilidad: restaurar una configuración de multipath validada, añadir health checks que afirmaran corrección del estado de rutas y ensayar failover en staging con el mismo firmware. La lección fue dolorosa: quitar capas no siempre es simplificación; a veces es quitar barandillas.

Mini-story 3: The boring but correct practice that saved the day

Una empresa mediana corría un clúster privado de Kubernetes con un driver CSI para block storage. Tenían dos distribuciones internas: «Linux estándar» y un OS minimal para hosts de contenedores. El OS minimal era popular porque arrancaba rápido y era más fácil de asegurar. También tenía la costumbre de faltar módulos del kernel que «todo el mundo asume».

Antes de permitirlo en producción, un SRE insistió en un suite de pruebas de «contrato de capacidades». No era glamuroso. Arrancaba un nodo, adjuntaba un volumen, ejecutaba un conjunto de checks en sysfs, verificaba opciones de montaje, hacía estrés de fsync y luego forzaba detach/reattach. También buscaba advertencias específicas del kernel y rechazaba avanzar si aparecía alguna cadena de «fallback» en dmesg.

En la primera ejecución la suite falló de inmediato: el nodo podía montar volúmenes, pero no soportaba una característica de filesystem requerida para snapshots. El driver CSI decía que los snapshots estaban soportados porque los objetos API existían. Por debajo, hacía fallback a un comportamiento de copia completa lento que funcionaba, pero habría fundido su presupuesto de almacenamiento y destruido tiempos de restauración.

La práctica que los salvó fue mundana: codificar suposiciones como tests. No «confiaron en el puerto». Probaron el puerto. El OS minimal siguió usándose, pero con una etiqueta clara: no snapshots hasta que la configuración del módulo y las características del filesystem coincidan con el contrato. Nadie recibió un pager y el CFO siguió ignorando lo cerca que estuvieron de financiar un festival de copia de datos sorpresa.

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

1) «Lo habilitamos, pero el rendimiento no cambió»

Síntoma: Activas una característica (discard, compresión, multipath, async I/O). Las métricas permanecen igual.

Causa raíz: La característica no se negocia de extremo a extremo o está deshabilitada en tiempo de ejecución por falta de capacidad.

Corrección: Valida de abajo a arriba: soporte del dispositivo (lsblk -D), advertencias del kernel (dmesg), opciones de montaje (findmnt) y estadísticas del driver.

2) «Funciona hasta el failover, luego se queda»

Síntoma: Latencia normal hasta una falla de ruta o mantenimiento; después la latencia de cola explota.

Causa raíz: Implementación parcial de semánticas de failover, política de rutas incorrecta o un puerto que no maneja estados transicionales correctamente.

Corrección: Ensaya failover deliberadamente. Revisa estado y salud de multipath. Prefiere configuraciones conservadoras conocidas en lugar de «stacks limpios» cuando la fiabilidad importa.

3) «Los snapshots existen, pero las restauraciones son lentísimas»

Síntoma: La API de snapshot tiene éxito; la restauración tarda una eternidad y machaca el almacenamiento.

Causa raíz: El puerto ofrece objetos de snapshot pero carece de soporte copy-on-write o snapshot nativo; hace fallback a copia completa.

Corrección: Verifica la implementación: capacidad del filesystem, soporte del backend de almacenamiento y patrones reales de I/O de restauración. Gatea el uso de snapshots por tipo de backend.

4) «La encriptación está activada, pero la CPU se dispara»

Síntoma: Activar TLS o cifrado de disco colapsa el throughput.

Causa raíz: Falta de aceleración hardware, comportamiento distinto del proveedor criptográfico o políticas que deshabilitan algoritmos y por tanto la negociación escoge opciones lentas.

Corrección: Inspecciona cifrados negociados, perfiles de CPU y disponibilidad de aceleración crypto. Escoge cifrados deliberadamente; no aceptes lo que entregue el handshake sin criterio.

5) «Los contenedores empezaron a fallar con errores raros de filesystem»

Síntoma: Errores de almacenamiento overlay, fallos raros en rename, peculiaridades de permisos.

Causa raíz: El filesystem de respaldo carece de características requeridas (d_type, xattrs), o la implementación de overlay del kernel difiere de lo que espera el runtime.

Corrección: Valida prerrequisitos de overlay y cambia el filesystem de respaldo o el driver. No ejecutes overlay sobre «lo que estuviera montado».

6) «Misma app, distinta distro, comportamiento distinto»

Síntoma: Timeouts, problemas DNS, distinto manejo de errores tras un cambio de imagen base.

Causa raíz: Diferencias de libc, comportamiento del resolver, valores por defecto de threading o sysctls del kernel cambiados.

Corrección: Trata la imagen base y la libc como parte de la API de la plataforma. Fija versiones, ejecuta tests de compatibilidad y compara sysctls.

7) «La característica está presente, pero no podemos observarla»

Síntoma: No hay métricas ni logs para confirmar el comportamiento; solo inferencia indirecta.

Causa raíz: El puerto omitió contadores/tracepoints o no los conectó a tu telemetría.

Corrección: Añade requisitos de observabilidad explícitos a los criterios de aceptación. Si no puedes observarlo, no puedes operarlo.

Listas de verificación / plan paso a paso: cómo desplegar puertos de forma segura

Paso a paso: construye un «contrato de capacidades» para tu plataforma

1. Lista las semánticas innegociables por carga de trabajo. Para bases de datos: corrección de fsync y latencia; para object storage: durabilidad y comportamiento de rebuild; para streaming: latencia de cola bajo backpressure.
2. Traduce semánticas en checks verificables. «Soporta discard» se convierte en «DISC-MAX > 0 y opción de montaje activada o trim periódico verificado.» «Soporta snapshots» se convierte en «la restauración no requiere copia completa.»
3. Documenta prerequisitos explícitamente. Opciones del kernel, módulos requeridos, firmware mínimo y características del filesystem de respaldo requeridas.
4. Crea un suite de validación automatizada. Ejecútala en cada nuevo kernel, imagen base y backend de almacenamiento. Falla rápido cuando las capacidades se desvían.
5. Incluye ejercicios de fallo. Desconecta una ruta, reinicia un nodo, llena el disco al 95%, fuerza resync, rota certificados. Mide impacto en SLOs.
6. Define tu política de fallback. Si una característica no se puede negociar, ¿el sistema debe negarse a arrancar o funcionar en modo degradado con alertas sonoras?
7. Gatea el despliegue por capacidad, no por nombre de host. «prod-storage-02» no es una capacidad. «discard soportado end-to-end» sí lo es.
8. Mantén una matriz de compatibilidad. No es novedoso; una tabla: versiones de kernel, versiones de drivers, firmware, banderas de características, advertencias conocidas.

Lista operativa: antes de aceptar que «portado» es «listo para producción»

• ¿Puedes demostrar que la característica se negocia end-to-end (cliente + servidor + kernel + dispositivo)?
• ¿Puedes demostrar que la característica cambia el comportamiento bajo carga (no solo el estado de configuración)?
• ¿Tienes al menos una prueba negativa donde la característica falta y el sistema falla ruidosamente?
• ¿Tienes observabilidad: contadores, logs y dashboards claros que muestren la salud de la característica?
• ¿Has probado la «ruta fea»: failover, resync, disco lleno, alta latencia, pérdida de paquetes?
• ¿Es seguro el rollback (banderas de pool, downgradear protocolos, compatibilidad de configuración)?

Reglas de decisión (con opinión, porque estás ocupado)

• Si la característica afecta la durabilidad o la integridad y no puedes validarla, desactívala y diseña en torno a esa realidad.
• Si la característica afecta el rendimiento y puede caer silenciosamente a fallback, alerta sobre el fallback o trata las afirmaciones de rendimiento como marketing.
• Si la característica es dependencia para tu respuesta a incidentes (snapshots, velocidad de restauración, observabilidad), no la lances sin ella.
• Si tu equipo de plataforma dice «debería funcionar», pide: prueba de config del kernel, prueba de capacidad negociada y un informe de ejercicio de fallo.

FAQ

1) ¿Cuál es la diferencia entre «la característica existe» y «la característica funciona»?

«Existe» significa que ves una perilla, módulo, API u opción de configuración. «Funciona» significa que el sistema toma la ruta de código prevista en condiciones realistas y puedes probarlo con observación y tests.

2) ¿Por qué los puertos se entregan con características stubbed?

Porque entregar paridad de API suele ser más fácil que entregar paridad semántica. Los stubs reducen fricción de integración y compran tiempo. El problema es cuando nadie etiqueta el stub como stub.

3) ¿Cómo ocurren los retrocesos silenciosos?

Muchos sistemas priorizan la disponibilidad. Si la negociación falla, eligen un protocolo anterior, un algoritmo más lento o un modo más seguro y siguen corriendo. Eso es genial para demos y terrible para SLOs a menos que detectes y alertes la degradación.

4) ¿Valen la pena las «matrices de compatibilidad»?

Sí, si las mantienes cortas y ligadas a tests de aceptación. El valor no es el documento; es la disciplina de saber qué combinaciones están probadas y cuáles son deseos.

5) ¿Cuál es la forma más rápida de saber si una característica de almacenamiento es real?

Revisa la capacidad del dispositivo (sysfs/lsblk), revisa advertencias del kernel (dmesg) y luego mide comportamiento (iostat latencia, pruebas de rebuild/failover). Si alguna capa discrepa, asume que la característica no es real.

6) ¿Cómo manejar afirmaciones de «soportado en Linux» de proveedores?

Traduce esa afirmación en: qué versiones de kernel, qué módulos, qué sistemas de archivos, qué firmware y qué escenarios de fallo están validados. Si no pueden responder, tú serás el laboratorio de pruebas.

7) ¿Deberíamos preferir menos capas (por ejemplo, quitar dm-multipath)?

Prefiere menos capas solo cuando puedas demostrar que la capa restante gestiona fallos y observabilidad al menos igual de bien. «Menos» no es automáticamente «más simple» en modos de fallo.

8) ¿Y si una característica faltante es solo un problema de rendimiento, no de corrección?

Los fallos de rendimiento se vuelven fallos de fiabilidad cuando disparan timeouts, reintentos, elecciones o retropresión. Trata la latencia de cola como un riesgo de disponibilidad, no solo una molestia de velocidad.

9) ¿Cómo hacemos que los equipos dejen de discutir si es culpa de la app o de la plataforma?

Haz que la plataforma publique un contrato de capacidades con tests y evidencia, y que los servicios declaren qué capacidades requieren. Entonces las discrepancias serán diffs y resultados de tests, no reuniones.

Conclusión: qué hacer la próxima semana, no el próximo trimestre

Los puertos con características faltantes no son bugs raros. Son el resultado natural de lanzar «presencia» antes que «comportamiento». La solución no es más optimismo. Es más verificación, contratos explícitos y menos retrocesos silenciosos.

Pasos prácticos:

1. Crea un contrato de capacidades para tu plataforma: el puñado de características de las que realmente dependes (durabilidad, snapshots, comportamiento multipath, negociación crypto, observabilidad).
2. Automatiza las comprobaciones mostradas arriba en CI para imágenes base, kernels y builds de nodos. Falla rápido cuando los prerequisitos se desvíen.
3. Ejecuta un ejercicio de fallo por cada característica crítica en staging: pérdida de ruta, reinicio de nodo, resync, restauración de snapshot, inyección de alta latencia.
4. Haz los retrocesos ruidosos: si el sistema degrada, alerta. Si no puede proveer una característica requerida, rehúsa arrancar.

Cuando alguien diga «está ahí», tu trabajo es preguntar: «¿Podemos probar que está activo, observable y correcto ante fallos?» Si no, trátalo como faltante. Producción lo hará.