ZFS vs mdadm: dónde mdraid gana y dónde pierde

Dos modelos mentales: almacenamiento como sistema de archivos vs almacenamiento como pila

Comparar ZFS con mdadm es un poco injusto porque no son el mismo tipo de cosa.
ZFS es un sistema de almacenamiento integrado: gestor de volúmenes + RAID + sistema de archivos + checksums + snapshots + primitivas de replicación.
mdadm es una capa de RAID por software. Crea un dispositivo de bloque. Aún necesitas poner LVM y un sistema de archivos (ext4, XFS, btrfs, etc.) encima.

Esa diferencia cambia dónde reside la corrección. Con mdraid, la integridad de datos está mayormente “en otro lado”:
tu sistema de archivos, tu aplicación, la verificación de backups y tu monitorización. Con ZFS, la integridad está integrada y es normativa:
cada bloque tiene checksum; scrub es una operación de primera clase; los snapshots son baratos; la replicación está diseñada para “enviar cambios, no copias completas”.

Si estás leyendo esto porque diseñas un sistema nuevo: no empieces preguntando “cuál es más rápido”.
Empieza preguntando: ¿qué fallos deben sobrevivirse sin heroísmos humanos?
Luego pregunta: ¿qué tareas operativas deben ser seguras a las 3 AM? La velocidad importa, pero la velocidad sin seguridad es solo una forma más rápida de obtener los datos equivocados.

Datos históricos e información útil (breve)

• ZFS se lanzó en 2005 (era Solaris) como reacción a sistemas de archivos que no podían detectar la corrupción silenciosa de forma fiable.
• mdraid precede a las “pilas de almacenamiento” modernas; lleva décadas en Linux y sigue siendo el modelo mental por defecto para muchos administradores: RAID, luego sistema de archivos.
• El “write hole de RAID5” no es folklore; es el riesgo real de pérdida de energía durante actualizaciones de paridad que deja franjas inconsistentes.
• ZFS RAIDZ fue diseñado para evitar el write hole mediante semántica copy-on-write y actualizaciones transaccionales.
• Los bitmaps de intención de escritura de mdraid existen precisamente para acelerar la resinc después de un apagado no limpio, con cierto coste de escritura.
• La adopción temprana de ZFS en Linux se ralentizó por fricciones de licencias; por eso ZFS no está “simplemente en mainline” como mdraid.
• ZFS introdujo snapshots prácticos aptos para producción como operaciones de metadatos baratas; muchos equipos construyeron flujos de trabajo de backup en torno a eso antes de que los “snapshots en la nube” fueran comunes.
• RAID6 en Linux maduró porque los discos crecieron mucho; las ventanas de reconstrucción se hicieron lo bastante grandes como para que la doble paridad dejara de ser “paranoia” y pasara a ser “normal”.

Dónde mdraid gana (y por qué)

1) Es aburrido en el mejor sentido: máxima compatibilidad

mdraid es un dispositivo de bloque. Esa es su superpotencia. Todo entiende dispositivos de bloque: LVM, dm-crypt, XFS, ext4, herramientas de bases de datos, instaladores de SO,
imágenes de nube, entornos de recuperación. Si quieres arrancar desde RAID1 en un instalador de una distro sin módulos adicionales, mdraid sigue siendo
el camino de menor resistencia.

Operativamente, eso significa que puedes mover el array entre máquinas y recuperarlo desde casi cualquier ISO de rescate de Linux.
Existen entornos de recuperación para ZFS, pero “disponible en todas partes” es una ventaja real de mdraid.

2) Características de rendimiento predecibles para cargas simples

mdraid no tiene ARC, no hace copy-on-write, no hace checksumming a nivel de sistema de archivos.
Eso puede traducirse en latencias más predecibles para ciertos patrones de escritura síncrona cuando se combina con un sistema de archivos conservador
y un planificador de E/S afinado.

RAID10 en mdraid es especialmente difícil de estropear. No siempre es lo más eficiente en espacio, pero es indulgente.
Para cargas sensibles a la latencia (bases de datos, colas) donde puedes costear los espejos extra, RAID10 de mdraid es una base sólida.

3) Más fácil de “componer” con cifrado y estándares existentes

El cifrado de ZFS es bueno, pero el ecosistema alrededor de dm-crypt/LUKS es enorme. Si tu equipo de cumplimiento ya tiene procedimientos,
gestión de claves y libros de jugadas de incidentes basados en LUKS, mdraid encaja limpiamente.

Ejemplo de pila que funciona bien: mdraid (RAID10) → LUKS → XFS. Es comprensible, testeable y relativamente fácil de recuperar.

4) Menor hambre de RAM, menos piezas móviles en memoria

ZFS quiere RAM. No porque sea descuidado, sino porque ARC y la caché de metadatos son parte de su diseño.
Si ejecutas nodos de huella pequeña (edge, appliances, VMs mínimas con discos directos), mdraid + ext4/XFS puede ser la única opción razonable.

Primera broma corta: mdraid es el equivalente de almacenamiento de un martillo de garra—poco sexy, ruidoso y de alguna manera siempre está en la caja cuando lo necesitas.

Dónde mdraid pierde (y cómo duele)

1) Detectar corrupción silenciosa no es su trabajo

mdraid no suma checksums de extremo a extremo. Si el disco devuelve datos incorrectos sin reportar un error (sí, sucede),
mdraid entrega alegremente esos datos erróneos a tu sistema de archivos. Algunos sistemas de archivos pueden detectar corrupción de metadatos, pero los datos de usuario generalmente no se verifican.

La consecuencia práctica: puedes tener lecturas “exitosas” de datos malos, y solo enterarte cuando una aplicación se queja—o peor, no se queja.
Tu mitigación se convierte en “mejores backups” y “verificaciones regulares”, lo cual es un plan, pero no una red de seguridad integrada.

2) El write hole de RAID5/6 y la fealdad de franjas parciales

El problema del write hole en RAID5: una pérdida de energía o crash durante una actualización de paridad puede dejar datos/paridad inconsistentes.
Lecturas posteriores pueden devolver corrupción sin señal clara. Hay mitigaciones: UPS, journaling de escritura por encima, o evitar RAID de paridad para datos críticos.
Pero el riesgo central existe.

Para arrays de paridad en mdraid, debes tratar un “apagado no limpio” como un incidente que merece verificación, no como una simple anécdota.
El bitmap ayuda a la velocidad de resinc, pero no prueba mágicamente la corrección de cada franja.

3) Las reconstrucciones pueden ser brutales y los controles son afilados

La velocidad de reconstrucción es un trade-off: ir rápido y derretir la latencia de producción; ir lento y extender la ventana de vulnerabilidad.
mdraid te da controles, pero son bastante globales, fáciles de olvidar y fáciles de configurar de forma que el equipo parezca muerto.

4) La observabilidad está fragmentada

Con mdraid vigilas: estado de mdadm, SMART por disco, logs del sistema de archivos, a veces LVM, a veces dm-crypt.
Nada de esto es imposible. Pero es una cabina con varios paneles, y las alarmas no siempre se correlacionan.

Dónde ZFS gana (y cuándo es la elección obvia)

1) Checksums de extremo a extremo y auto-reparación (cuando hay redundancia)

ZFS suma checksums de cada bloque y verifica en lectura. Si existe redundancia (mirror, RAIDZ), puede sanar leyendo otra copia y reparando.
Esto cambia el juego operativo: la corrupción se convierte en un evento detectado y accionable en lugar de una sospecha vaga.

Esta es la característica que mueve a ZFS de “sistema de archivos” a “sistema de integridad”.
Si almacenas algo que te daría vergüenza perder—datos de clientes, logs de auditoría, backups—esto importa.

2) Semántica copy-on-write: snapshots más seguros, actualizaciones de metadatos más seguras

ZFS escribe bloques nuevos y luego cambia punteros. Eso no es solo un truco; es la razón por la que los snapshots son baratos y por qué ciertos problemas de consistencia por crash son menos emocionantes que en pilas RAID de paridad.

También significa que la fragmentación y la amplificación de escritura pueden aparecer de formas sorprendentes si tratas a ZFS como ext4.
ZFS recompensa la planificación. Castiga los diseños “YOLO, publícalo” con latencias de cola impredecibles después.

3) Snapshots y replicación como operaciones de primera clase

Con ZFS, “tomar un snapshot” y “replicar incrementalmente” son operaciones normales, no añadidos.
Si tu historia RPO/RTO depende de copias puntuales rápidas y consistentes, ZFS suele ser la respuesta más limpia.

4) Claridad operativa: la salud del pool es una única señal veraz

zpool status te da una vista real y significativa de salud: degraded, faulted, checksum errors, resilver progress.
No es perfecta, pero es cohesiva. mdraid tiende a dispersar la verdad entre múltiples herramientas.

Segunda broma corta: ZFS recordará cada error que cometiste con recordsize—y a diferencia de tus compañeros, te mostrará gráficos.

Una cita sobre fiabilidad (idea parafraseada)

“Idea parafraseada” de Werner Vogels: construir sistemas esperando que las cosas fallen, y diseñar la recuperación como un modo normal de operación.

Patrones de arquitectura que realmente funcionan

Patrón A: mdraid RAID10 para bases de datos que odian las sorpresas

Si tienes una base de datos sensible a la latencia (PostgreSQL, MySQL, Elasticsearch hot tier) y puedes permitirte espejos,
mdraid RAID10 es una opción muy sensata. Combínalo con XFS o ext4. Añade un UPS. Monitoriza SMART y el estado de md.

Lo que no obtienes: integridad de extremo a extremo. Tu mitigación es verificación de backups y sumas periódicas offline a nivel de aplicación
(para datasets verdaderamente críticos).

Patrón B: ZFS mirror o RAIDZ2 para “me importa la corrección y la operabilidad”

El mirror de ZFS es la elección de baja fricción: resilvers rápidos, modos de falla simples, comportamiento predecible.
RAIDZ2 es excelente para capacidad con seguridad, especialmente para discos grandes donde las ventanas de reconstrucción son largas.

Para VMs, considera vdevs especiales, ajuste de recordsize y dispositivos de log separados solo cuando entiendas lo que hacen.
ZFS recompensa la simplicidad: mirrors + buena monitorización + flujos de trabajo de reemplazo probados.

Patrón C: mdraid + LUKS + XFS para organizaciones con cumplimiento estricto

Si la organización ya estandariza en herramientas LUKS, procesos de custodia de claves y recuperación “romper cristal”,
mdraid se integra de forma limpia. Esto no es tanto una victoria técnica como operativa.

Patrón D: ZFS para objetivos de backup y almacenamiento archivado

Los backups son donde la corrupción silenciosa va a retirarse. El scrub + checksums + snapshots de ZFS lo convierten en un objetivo sólido para backups,
incluso si tu almacenamiento primario no es ZFS.

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

Estos no son comandos “de juguete”. Son los que ejecutas cuando algo se siente raro y necesitas decidir si estás viendo un disco,
un controlador, una reconstrucción, un problema de caché o una aplicación haciendo algo cuestionable.

Task 1: Confirmar rápidamente la salud del array mdraid

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5]
md0 : active raid10 sdb1[1] sda1[0] sdd1[3] sdc1[2]
      1953383488 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]

unused devices: <none>

Qué significa: [4/4] [UUUU] indica que los cuatro miembros están activos. La ausencia de una línea de resync significa que no se está reconstruyendo.
Decisión: Si ves [U_UU] o una línea de resync/recovery, trátalo como degradado y verifica qué disco cayó.

Task 2: Obtener estado detallado de miembros de mdraid

cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Wed Nov  6 10:41:22 2024
        Raid Level : raid10
        Array Size : 1953383488 (1.82 TiB 2.00 TB)
     Used Dev Size : 976691744 (931.51 GiB 1000.20 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Thu Dec 26 01:12:09 2025
             State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

           Layout : near=2
       Chunk Size : 512K

Consistency Policy : resync

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync set-A   /dev/sda1
       1       8       17        1      active sync set-B   /dev/sdb1
       2       8       33        2      active sync set-A   /dev/sdc1
       3       8       49        3      active sync set-B   /dev/sdd1

Qué significa: State : clean es bueno. “failed” o “removed” significa problemas. El layout y el chunk afectan el rendimiento.
Decisión: Si el estado no es clean, inicia el flujo de trabajo de incidentes: identifica el miembro fallando, revisa SMART, programa reemplazo y evalúa el riesgo de reconstrucción.

Task 3: Encontrar qué dispositivo se comporta mal (triage SMART)

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep "Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|SMART overall-health"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3

Qué significa: Sectores pending y uncorrectable son una mala señal incluso si muestra “PASSED”.
Decisión: Planear reemplazo. Si el array está degradado, no esperes. Si es RAID de paridad, considera pausar cargas pesadas durante la reconstrucción.

Task 4: Comprobar salud del pool ZFS y tipos de errores

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
  scan: scrub repaired 0B in 00:21:10 with 0 errors on Thu Dec 26 00:40:02 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

errors: No known data errors

Qué significa: Los contadores READ/WRITE/CKSUM en 0 son el sueño. “scrub repaired” te dice si ZFS tuvo que sanar.
Decisión: Si ves errores CKSUM en un dispositivo, sospecha cableado/controlador o el disco. Si “errors: Permanent errors”, trátalo como pérdida de datos y restaura desde snapshot/replica.

Task 5: Detectar trampas de rendimiento de ZFS en propiedades del dataset

cr0x@server:~$ sudo zfs get compression,recordsize,atime,logbias,sync tank/db
NAME      PROPERTY     VALUE     SOURCE
tank/db   compression  lz4       local
tank/db   recordsize   128K      local
tank/db   atime        off       local
tank/db   logbias      latency   local
tank/db   sync         standard  local

Qué significa: recordsize impacta la amplificación de IO. sync afecta las semánticas de durabilidad.
Decisión: Para bases de datos con páginas de 8K/16K, considera recordsize=16K o 8K después de probar. No pongas sync=disabled a menos que te guste explicar pérdida de datos.

Task 6: Identificar si estás limitado por ARC de ZFS

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
01:12:10   890   220     24    40   18   170   77    10    5   24.1G  28.0G
01:12:11   910   260     28    60   23   190   73    10    4   24.1G  28.0G
01:12:12   870   240     27    55   23   175   73    10    4   24.1G  28.0G

Qué significa: Una tasa de misses alrededor de 25–30% puede estar bien o puede estar matándote, dependiendo de la carga.
Decisión: Si ARC está limitado respecto a la RAM y tu conjunto de trabajo es más grande, considera aumentar el máximo de ARC o añadir RAM. Si los misses son altos durante picos, considera un special vdev separado o discos más rápidos.

Task 7: Confirmar que la reconstrucción de mdraid está en curso y estimar radio de impacto

cr0x@server:~$ watch -n 2 cat /proc/mdstat
Every 2.0s: cat /proc/mdstat

md0 : active raid6 sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0]
      5855592448 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/4] [UUU_U]
      [=>...................]  recovery =  7.3% (107822080/1463898112) finish=215.0min speed=105000K/sec

Qué significa: Degradado ([5/4]) y recuperando a ~105 MB/s. ETA es aproximada.
Decisión: Si la latencia en producción es inaceptable, limita la velocidad de reconstrucción; si la ventana de riesgo es inaceptable, programa mantenimiento o reduce carga temporalmente.

Task 8: Ajustar la velocidad de reconstrucción de mdraid de forma segura (temporal)

cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_min
1000
cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_max
200000
cr0x@server:~$ echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max
50000

Qué significa: máximo de velocidad de reconstrucción limitado a ~50 MB/s. Esto reduce la contención.
Decisión: Úsalo cuando debas mantener la latencia estable. Revierte después y documenta el cambio. Si lo olvidas, estarás reconstruyendo hasta el próximo año fiscal.

Task 9: Comprobar salud a nivel de sistema de archivos en mdraid (ejemplo XFS)

cr0x@server:~$ mount | grep /data
/dev/md0 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k)
cr0x@server:~$ sudo xfs_repair -n /dev/md0
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
No modify flag set, skipping filesystem flush and exiting.

Qué significa: -n es solo lectura. Si reporta corrupción, programa downtime para una reparación real.
Decisión: Si existe corrupción y el array tuvo un apagado no limpio recientemente, trátalo como comportamiento probablemente relacionado con el write-hole en RAID de paridad. Verifica backups antes de reparar.

Task 10: Identificar culpables de latencia en ZFS en vivo

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        2.10T  1.40T    220    980  18.2M  95.4M
  raidz2-0  2.10T  1.40T    220    980  18.2M  95.4M
    sda         -      -     45    210  3.6M  19.1M
    sdb         -      -     46    195  3.7M  18.4M
    sdc         -      -     40    205  3.4M  19.0M
    sdd         -      -     44    220  3.5M  20.1M
----------  -----  -----  -----  -----  -----  -----

Qué significa: IO por disco balanceado sugiere que ningún disco individual está atascando. Si un disco muestra mucho menos ancho de banda u operaciones, sospecha de él.
Decisión: Si un disco va retrasado, corrobora con SMART y cableado. Si todos los discos están ocupados y la latencia es alta, estás limitado por la carga o infraaprovisionado.

Task 11: Reemplazar un disco fallado en mdraid (secuencia segura)

cr0x@server:~$ sudo mdadm --fail /dev/md0 /dev/sdc1
mdadm: set /dev/sdc1 faulty in /dev/md0
cr0x@server:~$ sudo mdadm --remove /dev/md0 /dev/sdc1
mdadm: hot removed /dev/sdc1 from /dev/md0
cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdf1
mdadm: added /dev/sdf1

Qué significa: El array comenzará la recuperación después de añadir. Vigila /proc/mdstat.
Decisión: Si la reconstrucción no inicia, verifica el tipo de partición, mismatch de versión de superblock o que hayas agregado la partición correcta.

Task 12: Reemplazar un disco fallado en ZFS (y asegurarse de que realmente esté reemplazando)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     FAULTED     12     0    45  too many errors
            sdd     ONLINE       0     0     0

cr0x@server:~$ sudo zpool replace tank sdc /dev/sde
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 01:14:02 2025
        148G scanned at 1.45G/s, 36.1G issued at 354M/s, 2.10T total
        36.1G resilvered, 1.68% done, 01:39:40 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              sdc     FAULTED     0     0     0
              sde     ONLINE       0     0     0  (resilvering)
            sdd     ONLINE       0     0     0

Qué significa: ZFS muestra un vdev “replacing” mientras hace resilver. Esa es tu confirmación de que no estás solo añadiendo un disco al azar.
Decisión: Si la velocidad de resilver es baja, revisa actividad del pool, discos SMR o problemas de controlador. Si los errores suben en otros discos durante el resilver, pausa y reevalúa el riesgo.

Task 13: Verificar superblocks de mdraid cuando el ensamblaje es extraño

cr0x@server:~$ sudo mdadm --examine /dev/sda1 | egrep "Array UUID|Raid Level|Device Role|State"
Array UUID : 1c2b7d1f:0e4c1c0a:4b2330c3:b51e1c66
Raid Level : raid10
Device Role : Active device 0
State : clean

Qué significa: Confirma que el miembro pertenece al array esperado.
Decisión: Si los UUIDs difieren entre miembros, podrías estar mezclando discos de arrays diferentes. Para y mapea todo antes de ensamblar nada.

Task 14: Detectar “mi pool está lleno y ahora todo está lento” en ZFS

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  3.40T   120G    96K  /tank

Qué significa: 120G libres en un pool de varios TB puede ser peligrosamente poco dependiendo de la carga.
Decisión: Si el espacio libre está por debajo de ~10–20% en pools ocupados, planifica limpieza o expansión inmediata. El rendimiento de ZFS y el comportamiento del asignador se degradan cuando el pool está justo.

Task 15: Comprobar uso del bitmap de intención de escritura en mdraid

cr0x@server:~$ sudo mdadm --detail /dev/md0 | egrep "Intent Bitmap|Bitmap"
     Intent Bitmap : Internal

Qué significa: El bitmap está habilitado; la resinc después de un crash será más rápida (solo regiones cambiadas).
Decisión: Para arrays de paridad en sistemas que pueden caer o reiniciarse, el bitmap suele valer el pequeño coste de escritura. Para cargas de alto write, mide el impacto.

Task 16: Confirmar que el cuello de botella es IO (no CPU, no memoria)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server)  12/26/2025  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    3.44   22.10    0.00   66.34

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await  w/s     wkB/s   w_await  aqu-sz  %util
md0             120.0  18000.0     0.0    0.0     8.4  980.0  98000.0    34.2    18.7   98.0

Qué significa: Alto %iowait y %util ~98% indica almacenamiento saturado. w_await ~34ms es doloroso para apps sensibles a latencia.
Decisión: Si esto ocurre durante una reconstrucción, limita la velocidad o reduce carga. Si es estado estable, necesitas más spindles, SSDs, mejor nivel RAID o cambios en la carga.

Guía rápida de diagnóstico

Cuando el almacenamiento se pone “lento”, tu primer trabajo es evitar perder tiempo. Tu segundo trabajo es evitar empeorarlo.
Este orden está diseñado para identificar cuellos de botella en minutos, no horas.

Primero: ¿estamos reconstruyendo o degradados?

• mdraid: cat /proc/mdstat y mdadm --detail /dev/mdX. Busca recovery, resync, [U_U].
• ZFS: zpool status. Busca DEGRADED, resilver, contadores READ/WRITE/CKSUM en aumento.

Si es así: espera latencia. Decide si limitar la reconstrucción o programar una ventana de mantenimiento. No discutas con la física.

Segundo: ¿es un solo disco, un bus o todo el array?

• iostat -xz 1 para ver saturación y tiempos await.
• zpool iostat -v 1 para ver si un vdev/dispositivo va retrasado.
• smartctl -a en discos sospechosos; busca pending/uncorrectable y errores CRC (a menudo cableado).

Un disco malo puede arrastrar a todo el array a la miseria mucho antes de “fallar”. Por eso la monitorización debería alertar sobre degradación SMART, no solo discos muertos.

Tercero: confirmar el patrón de carga

• ¿Escrituras sync altas? Revisa configuraciones de aplicación, comportamiento de fsync y en ZFS revisa sync/logbias.
• ¿Lecturas aleatorias con baja cache hit? Revisa estadísticas ARC de ZFS o presión de la page cache de Linux.
• ¿Pequeñas escrituras en RAIDZ/RAID5? Espera amplificación de escritura y coste de paridad.

Cuarto: verifica límites “aburridos” que causan gran dolor

• Pool ZFS demasiado lleno (poco espacio libre).
• Límites de velocidad de reconstrucción de mdraid accidentalmente fijados bajos/altos.
• Errores de controlador en dmesg (timeouts, resets).
• Particiones desalineadas o tamaños de sector raros al mezclar discos.

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

1) Síntoma: un array de paridad devuelve archivos corruptos tras pérdida de energía

Causa raíz: exposición al write hole de RAID5/6 + apagado no limpio, además de falta de checksums de extremo a extremo.

Solución: Prefiere RAID10 o ZFS RAIDZ con copy-on-write para datos críticos. Si te quedas en paridad mdraid: UPS + write-intent bitmap + prácticas de apagado consistentes + herramientas de verificación.

2) Síntoma: la reconstrucción de mdraid deja producción inutilizable

Causa raíz: reconstrucción que satura IO; speed_limit_max demasiado alto; reconstrucción de paridad leyendo/escribiendo franjas completas.

Solución: Limita reconstrucción (/proc/sys/dev/raid/speed_limit_max), planifica ventanas de reconstrucción y considera RAID10 para cargas OLTP sensibles a latencia.

3) Síntoma: pool ZFS está ONLINE pero las aplicaciones ven corrupción aleatoria

Causa raíz: a menudo no es ZFS en sí—más comúnmente RAM mala en sistemas sin ECC, o un controlador defectuoso que miente sobre escrituras.

Solución: Ejecuta pruebas de memoria, revisa eventos ECC, inspecciona dmesg por resets de controlador. En ZFS, confía en los errores de checksum: si suben, el hardware es culpable hasta que se demuestre lo contrario.

4) Síntoma: picos de latencia al habilitar snapshots para todo

Causa raíz: churn de snapshots + fragmentación + desajuste de recordsize para la carga, especialmente en datasets de VM muy activos.

Solución: Reduce frecuencia/retención de snapshots en datasets calientes, afina recordsize/volblocksize adecuadamente, considera pools separados para imágenes de VM vs archivos generales.

5) Síntoma: el array mdraid se monta pero los sistemas de archivos no arrancan limpios

Causa raíz: el dispositivo de bloque subyacente “está bien”, pero la metadata del sistema de archivos sufrió (apagado no limpio, errores de hardware).

Solución: Realiza comprobaciones de sistema de archivos (xfs_repair / fsck) en modo mantenimiento; confirma backups antes de reparaciones que puedan descartar metadata.

6) Síntoma: resilver de ZFS tarda una eternidad en comparación a lo esperado

Causa raíz: Resilver lee solo bloques asignados (bueno), pero igualmente puede ser lento por discos SMR, fragmentación del pool, IO concurrente pesado o dispositivo lento.

Solución: Identifica dispositivo lento con zpool iostat -v, evita SMR para vdevs, mantiene espacio libre saludable en el pool, planifica resilvers fuera de pico.

7) Síntoma: “Reemplazamos un disco pero el array sigue degradado”

Causa raíz: Reemplazaron la partición equivocada, nombre de dispositivo incorrecto, o confusión entre replace/add en ZFS; en mdraid, el disco no se añadió realmente como miembro.

Solución: Para mdraid, verifica con mdadm --detail y revisa roles de miembros. Para ZFS, busca el vdev “replacing” en zpool status y confirma que el nuevo disco está resilvering.

Tres microrelatos corporativos desde la trinchera

Microrelato 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba mdraid RAID6 bajo XFS para un almacenamiento de archivos compartido. La suposición era simple:
“RAID6 significa que dos discos pueden fallar, así que estamos seguros.”

La máquina sufrió un evento de energía fuerte. Arrancó. El array md se ensambló. /proc/mdstat decía que todo estaba clean.
Los usuarios empezaron a quejarse de archivos y archivos comprimidos “aleatoriamente” corruptos. Nada era lo bastante consistente como para señalar un solo directorio.

El equipo persiguió bugs de aplicación durante un día. Luego alguien comparó checksums contra el backup offsite y encontró desajustes en archivos que se modificaron justo antes del corte.
No había errores claros de disco. SMART parecía “bien”. El array decía la verdad desde su perspectiva: no sabía que la relación paridad/datos estaba inconsistente.

Causa raíz: la clásica ventana de inconsistencia de paridad durante el crash—efectivamente el write hole se hizo visible. La metadata de XFS estaba mayormente bien,
así que los mounts parecían normales. La corrupción vivía en datos de usuario donde no existían checksums de extremo a extremo.

La solución no fue ingeniosa. Restauraron los datasets afectados desde backups y cambiaron el diseño: ZFS para el file store con scrubs y snapshots,
o mdraid RAID10 para datos calientes donde no podían migrar inmediatamente. Además, desde entonces trataron “apagado no limpio en RAID de paridad” como un incidente real.

Microrelato 2: La optimización que salió mal

Un equipo financiero usaba ZFS para almacenamiento de VM y quería más IOPS. Alguien notó “las escrituras sync son lentas” y tomó la tentadora decisión:
poner sync=disabled en el dataset de VM.

Los benchmarks se veían fantásticos. La latencia bajó. Los gráficos se calmaron. El cambio pasó silenciosamente a “tuning estándar.”
Nadie lo documentó porque, bueno, “funcionó”.

Semanas después, un hypervisor se reinició inesperadamente (ni siquiera un corte de energía—solo un kernel panic por un driver no relacionado).
Varias VMs volvieron con bases de datos que no arrancaban, o peor, arrancaron con pérdida sutil de transacciones.
El almacenamiento estaba bien. El pool estaba ONLINE. El daño estaba en la consistencia a nivel de aplicación: escrituras reconocidas que nunca llegaron a almacenamiento estable.

El postmortem fue doloroso porque no fue misterioso. El sistema estaba configurado para mentir sobre la durabilidad.
Y las VMs confiaban en ello. Porque eso es lo que hacen las computadoras.

Revirtieron a sync=standard, añadieron un dispositivo SLOG apropiado para las cargas que necesitaban escrituras sync de baja latencia, y actualizaron la gestión de cambios:
cualquier ajuste que afecte durabilidad requiere aprobación explícita de riesgo. “Rápido” no es un requisito de negocio si “correcto” es opcional por accidente.

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

Un equipo empresarial ejecutaba una mezcla: mdraid RAID10 para servidores de base de datos, ZFS para objetivos de backup. Nada revolucionario.
Lo que sí hacían era una práctica aburrida: “simulacros de recuperación” mensuales que incluían reemplazar un disco en un entorno de staging,
ensamblar un array md desde discos fríos y restaurar un dataset ZFS desde replicación incremental.

Un viernes, un nodo de base de datos empezó a registrar timeouts de IO intermitentes. SMART mostró aumento de errores CRC en un solo disco.
A menudo eso es cable o backplane, pero en RAID10 sigue siendo señal de “reemplazar algo”. Fallaron y removieron el miembro,
cambiaron la unidad y comenzaron la reconstrucción. Rutina.

Durante la reconstrucción, un segundo disco en el mismo backplane empezó a dar errores y se cayó. No completamente muerto, pero fallando.
Como monitorizaban proactivamente, el on-call ya tenía el plan de repuesto, la secuencia exacta de comandos y los umbrales de “parar si X ocurre”.

Pausaron la velocidad de reconstrucción, desviaron tráfico de lectura del nodo y usaron el tiempo para cambiar el cable/slot del backplane sospechoso.
El array se estabilizó y completó la recuperación sin perder datos. Sin heroísmos. Sin improvisación.

La nota post-incidente fue casi aburrida: “Se siguió el runbook.” Ese es el punto.
Aburrido es lo que quieres del almacenamiento. La emoción pertenece a las demos de producto, no a tu capa de bloques.

Listas de verificación / plan paso a paso

Elegir entre ZFS y mdraid (lista de decisiones)

1. Si necesitas integridad de extremo a extremo (detectar + sanar corrupción): elige ZFS.
2. Si necesitas máxima portabilidad y rutas de arranque/instalación simples: mdraid gana, especialmente RAID1 para root.
3. Si ejecutas bases de datos y puedes permitir espejos: mdraid RAID10 o mirrors de ZFS. Evita RAID de paridad para OLTP caliente a menos que se pruebe a fondo.
4. Si dependes de snapshots para RPO/RTO: ZFS ofrece la historia operativa más limpia.
5. Si tu presupuesto de RAM es ajustado: mdraid + XFS/ext4 suele ser menos exigente.
6. Si tu organización tiene flujos LUKS para cumplimiento: mdraid se integra naturalmente; el cifrado de ZFS está bien pero es operacionalmente distinto.

Plan de despliegue en producción (pasos seguros)

1. Elige el nivel RAID según el dominio de fallo y la ventana de reconstrucción, no solo por capacidad.
2. Estándariza modelos de disco dentro del vdev/array cuando sea posible; evita mezclar SMR con CMR donde importe.
3. Habilita monitorización antes del go-live: alertas mdadm, alertas SMART, estado de pool ZFS, estado de scrub, gráficos de latencia e IB saturación.
4. Define política de scrub/check:
   • ZFS: zpool scrub regular y alerta en bytes reparados o checksum errors.
   • mdraid: chequeos de consistencia periódicos (y entender qué garantizan y qué no).
5. Prueba el procedimiento de reemplazo de disco en un nodo no prod con tu hardware exacto.
6. Documenta el impacto de rendimiento de rebuild/resilver y define cuándo limitar.
7. Backups: implementa y prueba la restauración, no solo los jobs de backup.
8. Haz un game day: simula una falla de disco, luego un segundo disco “flaky”, y observa cómo actúa la gente.

Plan de respuesta a incidentes para un array/pool degradado

1. Congela cambios: detén “optimizaciones”, detén reequilibrios, detén reinicios aleatorios.
2. Recopila estado: /proc/mdstat + mdadm --detail o zpool status.
3. Identifica el componente fallando: SMART, logs, resets de controlador.
4. Decide: reemplazar ahora vs limitar reconstrucción vs evacuar carga.
5. Reemplaza usando la secuencia correcta de herramientas (mdadm fail/remove/add o zpool replace).
6. Monitoriza reconstrucción/resilver y vigila errores secundarios.
7. Post-recuperación: ejecuta scrub/check, luego haz una verificación de datos dirigida y valida backups.

Preguntas frecuentes (FAQ)

¿ZFS es siempre más seguro que mdraid?

Más seguro contra corrupción silenciosa y muchos problemas de consistencia, sí—porque suma checksums y puede auto-sanar con redundancia.
Pero ZFS aún depende de hardware sensato. RAM mala o un controlador que miente puede arruinar el día de cualquiera.

¿mdraid está “obsoleto” ahora que existe ZFS?

No. mdraid sigue siendo un bloque de construcción sólido para flotas Linux, especialmente para RAID1/10 y entornos que demandan portabilidad y simplicidad.
No es lo último; es utilizable. La producción prefiere lo utilizable.

¿Debería usar RAID5 de mdraid para datos importantes?

Si “importante” significa “no tolero corrupción silenciosa”, evítalo. Si debes usar RAID de paridad, mitiga agresivamente:
UPS, write-intent bitmap, monitorización fuerte, backups verificados y procedimientos de recuperación documentados. O usa RAIDZ de ZFS en su lugar.

¿Por qué las reconstrucciones de mdraid parecen peores que los resilvers de ZFS?

mdraid suele tocar grandes porciones del dispositivo (dependiendo del nivel y uso del bitmap).
ZFS resilver típicamente copia solo bloques asignados, lo que puede ser mucho menos datos—a menos que el pool esté casi lleno o muy fragmentado.

¿Puedo apilar ZFS encima de mdraid?

Puedes, pero usualmente no deberías. Estás duplicando lógica RAID, complicando modos de fallo y difuminando dónde vive la integridad.
Si quieres características de ZFS, dale discos directos (HBAs, no controladoras RAID) y déjalo hacer su trabajo.

¿Cuál es el mejor nivel RAID para bases de datos?

Los espejos son la respuesta por defecto: mdraid RAID10 o mirrors de ZFS. RAID de paridad puede funcionar para cargas de solo lectura o por lotes,
pero es menos indulgente y a menudo menos predecible bajo presión de escritura.

¿Necesito RAM ECC para ZFS?

Es fuertemente recomendable para sistemas donde la corrección importa. ZFS detectará corrupción en disco; no puede prevenir que una RAM mala
genere datos malos antes de que se calcule el checksum. ECC reduce sustancialmente esa clase de riesgo.

¿La compresión en ZFS es segura y útil?

Sí—lz4 es ampliamente usado y típicamente una ganancia, especialmente para texto, logs, imágenes de VM y muchas bases de datos.
Puede reducir IO y aumentar el rendimiento efectivo. Mide impacto en CPU, pero la mayoría de CPUs modernas lo manejan cómodamente.

¿Cuál es el equivalente en mdraid de scrub de ZFS?

mdraid puede hacer comprobaciones de consistencia, pero no ofrece checksums de extremo a extremo. Un chequeo de paridad puede detectar desajustes paridad/datos,
pero no puede probar la corrección de datos de usuario como lo hace ZFS.

¿Cómo elijo entre ZFS RAIDZ2 y mdraid RAID6?

Si quieres paridad con garantías de corrección más fuertes y herramientas integradas, RAIDZ2 suele ser la mejor elección operativa.
Si necesitas un dispositivo de bloque para pilas existentes y confías en tus mitigaciones operacionales, RAID6 es viable—pero trata los eventos de energía seriamente.

Próximos pasos prácticos

Si estás construyendo nuevo almacenamiento para producción y no tienes una restricción especial que te empuje a otra cosa, por defecto usa mirrors ZFS o RAIDZ2,
mantén el diseño simple y programa scrubs regulares con alertas. Combínalo con RAM ECC cuando puedas. Haz de los snapshots parte de tu historia de backups,
no un detalle de último minuto.

Si ya estás en mdraid y funciona: no migres en pánico. En su lugar, mejora las operaciones:
verifica monitorización SMART, confirma tu estrategia de limitación de reconstrucción, añade write-intent bitmap donde corresponda y practica procedimientos de recuperación.
Luego decide si las características de integridad (no solo rendimiento) justifican una migración a ZFS para datasets específicos como backups y file stores.

La mejor elección es la que tu equipo puede operar correctamente bajo estrés. La segunda mejor elección es la que falla lo suficientemente ruidosamente como para que la notes.