ZFS vs Storage Spaces: Por qué ‘fácil’ puede volverse ‘opaco’

Qué significa “opaco” en producción

“Opaco” no es un insulto. Es una propiedad: el sistema oculta estado importante detrás de abstracciones amistosas y, cuando el rendimiento
o la fiabilidad se desvían, no puedes responder rápidamente:

• ¿Qué dispositivos físicos están lentos ahora mismo?
• ¿Está la redundancia degradada actualmente?
• ¿El sistema está reparando datos, reconfigurando el layout o limitando escrituras?
• ¿El problema es capacidad, fragmentación, presión de metadatos, fallos de caché o un único disco que está muriendo?

Las abstracciones son útiles. Permiten que un generalista despliegue almacenamiento sin convertirse en arqueólogo de sistemas de archivos. Pero la abstracción es
un intercambio: ganas facilidad y pierdes inmediatez. Si tu plataforma ya tiene una cultura operativa fuerte—SLOs claros, telemetría consistente,
respuesta a incidentes practicada—puedes sobrevivir con algo más opaco. Si no la tienes, la abstracción gustosamente te cubrirá los ojos mientras corres hacia el precipicio.

Tengo sesgo hacia sistemas donde la evidencia es local, estructurada y difícil de falsear. ZFS hace esto bien. Storage Spaces también puede hacerlo,
pero en la práctica es más común encontrarse con razonamientos del tipo “debería funcionar” en lugar de “aquí está la cadena de pruebas”.

Filosofías diferentes: verdad autodescriptiva vs abstracción gestionada

ZFS: el sistema de archivos que trata el almacenamiento como una base de datos

ZFS no es solo “un RAID y un sistema de archivos.” Es una pila de almacenamiento construida alrededor de checksums de extremo a extremo, semántica copy-on-write y
un modelo coherente de verdad: bloques de datos y bloques de metadatos se referencian entre sí de forma que la corrupción puede detectarse y,
con redundancia, repararse.

Operativamente, ZFS suele recompensarte por aprender su vocabulario: vdevs, pools, datasets, snapshots, ARC, grupos de transacción,
scrubs, resilvers. Una vez que aprendes los sustantivos, los verbos se comportan de forma consistente. El sistema es opinado y en gran medida honesto. Cuando
está enfadado, normalmente te dice por qué—a veces de forma ruda, pero clara.

Storage Spaces: la mentalidad de “tejido de almacenamiento”

Storage Spaces es una capa de virtualización de almacenamiento de Windows: agregas discos físicos en pools, creas discos virtuales con
resiliencia (mirror, parity) y luego formateas volúmenes encima. En el mundo de Storage Spaces Direct (S2D), escalas esto a través de
nodos con clustering.

Las fortalezas son evidentes en entornos corporativos:

• Encaja con las herramientas de gestión de Windows y los modelos de identidad.
• Es “clicable” y scriptable con PowerShell.
• Se integra con clustering y funciones de Windows Server.

La debilidad también es obvia cuando has estado de guardia: la capa de almacenamiento se convierte en una experiencia mediada. Cuando la paridad está lenta,
cuando un disco es marginal, cuando la caché de escritura se comporta mal, las capas “útiles” del sistema pueden hacer que el análisis de causa raíz
se sienta como discutir con un conserje sobre dónde aparcó tu coche.

Una cita que vale la pena poner en la pared, porque aplica a ambas pilas: “La esperanza no es una estrategia.” — General Gordon R. Sullivan.

Broma #1: El almacenamiento es como una hoja de cálculo compartida—todos confían en ella hasta que las fórmulas empiezan a devolver “#REF!” al final del trimestre.

Hechos e historia que siguen importando

Algunos puntos de contexto concretos—porque el “por qué” a menudo se esconde en el “cuándo”:

1. ZFS nació en Sun como parte de Solaris, diseñado en una época en que los controladores RAID mentían y la degradación de bits no era teórica.
2. Checksums de extremo a extremo fueron una motivación central de ZFS: el sistema asume que los discos, cables y controladores pueden corromper datos silenciosamente.
3. ZFS popularizó copy-on-write para almacenamiento de propósito general, habilitando snapshots baratos y estado consistente en disco tras fallos.
4. “RAID-Z” fue la respuesta de ZFS al problema del write hole en implementaciones clásicas de RAID-5/6.
5. Storage Spaces llegó con Windows 8 / Server 2012 como el intento de Microsoft de ofrecer almacenamiento en pool sin RAID del proveedor.
6. Storage Spaces Direct (S2D) luego extendió el modelo hacia un diseño clusterizado e hiperconvergente para Windows Server.
7. La integración con ReFS se volvió una parte clave de la historia de almacenamiento de Microsoft, con streams de integridad y resiliencia de metadatos (aunque el comportamiento depende de la configuración).
8. Ambos ecosistemas aprendieron lecciones dolorosas sobre caché: la caché de escritura puede ahorrar rendimiento y también magnificar modos de fallo cuando está mal dimensionada o sin protección.

Esto no es trivia. Explica por qué ZFS está obsesionado con señales de corrección (checksums, scrubs) y por qué Storage Spaces a menudo asume que quieres
una política de almacenamiento que “simplemente funcione” hasta que no lo hace.

Cómo se ven las fallas: ZFS vs Storage Spaces

Forma de fallo 1: corrupción latente y “restauramos basura”

El movimiento distintivo de ZFS es detectar corrupción durante lecturas y scrubs. Si existe redundancia, ZFS puede reparar desde una copia buena. Esto no es magia; son checksums consistentes y redundancia en la capa correcta. La ventaja operativa es que puedes probar la integridad, no solo asumirla.

Storage Spaces puede ofrecer características de integridad dependiendo del sistema de archivos (ReFS) y las opciones. Pero en muchas implementaciones, la integridad es un pensamiento secundario. Verás “el disco está sano” mientras la corrupción a nivel de aplicación se cocina en silencio porque la pila no fue configurada para detectarla de extremo a extremo.

Forma de fallo 2: comportamiento de reconstrucción y la larga cola del dolor

El resilver de ZFS es lógico: reconstruye solo bloques asignados (para algunas topologías), no necesariamente el disco completo. Eso puede ser
una gran ventaja operativa cuando los pools son grandes pero están mayormente vacíos. La larga cola es que un pool fragmentado o con alta presión de
metadatos puede hacer que los resilvers sean lentos y disruptivos.

Las reparaciones en Storage Spaces dependen del layout y de si estás en Storage Spaces tradicional o en S2D. En layouts de paridad especialmente,
las reparaciones pueden ser castigos, y el sistema puede priorizar la “corrección” de una manera que haga que tu carga de producción parezca relegada a ruido de fondo. Lo aterrador es que el trabajo de reparación a veces es menos obvio para los operadores a menos que conozcan los cmdlets y contadores correctos.

Forma de fallo 3: acantilados de rendimiento

ZFS tiene acantilados previsibles:

• Desajuste de recordsize y escrituras aleatorias pequeñas pueden perjudicar.
• Malentendidos sobre SLOG pueden crear dispositivos placebo o cuellos de botella reales.
• Presión en ARC se manifestará como misses de caché y amplificación de I/O.
• Pool casi lleno es clásico: la fragmentación y el coste de asignación suben.

Storage Spaces tiene acantilados diferentes:

• Penalización de escritura por paridad es real, y “es solo paridad” se vuelve “por qué todo está 10x más lento.”
• Provisión delgada puede convertirse en una parada súbita cuando se agota la capacidad física.
• Nivelado y caché pueden lucir bien en benchmarks y raros en producción cuando cambia el working set.
• Trabajos de fondo (reparar, optimizar, reequilibrar) pueden robar rendimiento sin alarmas de cara al usuario.

Forma de fallo 4: el factor humano—qué anima el sistema a que ignores

ZFS te anima a mirar zpool status, calendarios de scrub y contadores de errores. Storage Spaces te anima a mirar “HealthStatus: Healthy” y confiar en la abstracción. Eso está bien hasta que la abstracción está resumiendo justo el detalle que necesitabas saber: qué disco está con timeouts, qué bahía está intermitente, qué porción de capacidad está sobrecomprometida.

Tareas prácticas para el operador (comandos, salidas, decisiones)

Estos no son comandos “de juguete”. Son los que ejecutas durante un incidente y de nuevo en el postmortem, cuando decides si la plataforma es confiable o simplemente silenciosa con educación.

Task 1 (ZFS): Comprobar la salud del pool y el recuento de errores

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.
  scan: scrub repaired 0B in 06:21:14 with 1 errors on Wed Dec  4 02:18:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     1

errors: Permanent errors have been detected in the following files:

        tank/data/app.db

Qué significa: El pool está online, pero se detectó un error de checksum y se localizó en un archivo. Eso no es “está bien.”
Es una historia: un sector malo, un cable, un controlador o memoria. ZFS lo detectó; ahora debes responder.

Decisión: Restaura o reconstruye el archivo afectado desde una fuente conocida buena, luego investiga el dispositivo con errores CKSUM. Si los errores se repiten, reemplaza esa ruta de disco (unidad, cable, puerto HBA) incluso si SMART parece “bien.”

Task 2 (ZFS): Confirmar calendario de scrub y resultado del último scrub

cr0x@server:~$ zpool status tank | sed -n '1,15p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 06:21:14 with 0 errors on Wed Dec 18 02:11:05 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
errors: No known data errors

Qué significa: El scrub se completó, no reparó nada y no encontró errores. Esa es tu prueba periódica de integridad.

Decisión: Si no ves scrubs completándose regularmente, prográmalos. Si los scrubs tardan más con el tiempo, tómatelo como una señal de capacidad/rendimiento (fragmentación, discos lentos, unidades SMR o un cambio de carga de trabajo).

Task 3 (ZFS): Identificar latencia de I/O a nivel de vdev

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.1T  7.8T     90    420   12.3M  55.4M
  raidz2-0                  12.1T  7.8T     90    420   12.3M  55.4M
    wwn-...c3d4                 -      -     12     58  1.6M   7.6M
    wwn-...c3d5                 -      -     11     54  1.5M   7.1M
    wwn-...c3d6                 -      -     12     57  1.6M   7.4M
    wwn-...c3d7                 -      -     55    197  6.3M  26.0M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Un disco está realizando trabajo desproporcionado. A veces eso es normal (bloques calientes, un hermano lento o una falla parcial que empuja lecturas a otro disco). También es la forma de detectar un disco que “funciona” pero no puede seguir el ritmo.

Decisión: Correlaciona con SMART y logs del kernel. Si un dispositivo muestra comportamiento diferente de forma consistente, reemplázalo preventivamente o al menos muévelo a otra bahía/cable para aislar la ruta.

Task 4 (ZFS): Comprobar el comportamiento del ARC (presión de memoria vs tasa de aciertos)

cr0x@server:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01  8120   610      7   210   34   400   66     0    0   58G   64G
12:10:02  7901   645      8   240   37   405   63     0    0   58G   64G
12:10:03  8012   702      9   260   37   442   63     0    0   58G   64G
12:10:04  7998   690      9   250   36   440   64     0    0   58G   64G
12:10:05  8105   720      9   270   38   450   62     0    0   58G   64G

Qué significa: Una tasa de misses ~9% no es inherentemente mala, pero si la latencia es alta y los misses están subiendo, los discos hacen más trabajo. “arcsz” cercano a “c” significa que ARC está en el tamaño objetivo; puede seguir existiendo presión de memoria en otras partes.

Decisión: Si los misses se disparan bajo carga, añade RAM, reduce el working set, ajusta recordsize/compression, o considera
dispositivos especiales para vdev/metadata con cuidado. No añadas L2ARC como primer movimiento a menos que conozcas tu patrón de lectura.

Task 5 (ZFS): Confirmar propiedades del dataset que influyen en el rendimiento

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,atime,logbias tank/data
NAME       PROPERTY     VALUE
tank/data  atime        off
tank/data  compression  zstd
tank/data  logbias      latency
tank/data  recordsize   128K

Qué significa: Estas configuraciones modelan los patrones de I/O. recordsize impacta la amplificación; la compresión puede reducir I/O; logbias afecta el manejo de escrituras síncronas en algunos casos.

Decisión: Si este dataset es una base de datos con páginas de 16K, recordsize de 128K puede estar mal. Cámbialo antes
de la próxima carga grande y valida. Estás gestionando física, no vibras.

Task 6 (ZFS): Vigilar que un pool no se llene demasiado

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   12.1T 7.8T   128K   /tank

Qué significa: La capacidad parece bien ahora. Pero el umbral operativo real no es “100% lleno.” Para muchos pools,
el rendimiento y el comportamiento de asignación se degradan sustancialmente mucho antes, especialmente con RAIDZ y espacios libres fragmentados.

Decisión: Trata ~80% como el inicio de conversaciones serias, y ~85–90% como “dejar de añadir datos a menos que también añadas vdevs.” Establece cuotas/reservas para inquilinos ruidosos.

Task 7 (ZFS): Reemplazar un disco correctamente y verificar progreso del resilver

cr0x@server:~$ zpool replace tank wwn-0x5000c500a1b2c3d7 /dev/disk/by-id/wwn-0x5000c500a1b2c3ff
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Dec 19 03:14:22 2025
        1.27T scanned at 1.12G/s, 412G issued at 362M/s, 8.41T total
        412G resilvered, 4.78% done, 06:23:10 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            wwn-...c3d4             ONLINE       0     0     0
            wwn-...c3d5             ONLINE       0     0     0
            wwn-...c3d6             ONLINE       0     0     0
            replacing-3             DEGRADED     0     0     0
              wwn-...c3d7           OFFLINE      0     0     0
              wwn-...c3ff           ONLINE       0     0     0

Qué significa: ZFS está resilverizando. La salida te da un ETA y throughput. La topología muestra “replacing”
que es exactamente el estado que quieres ver en mitad de la operación.

Decisión: Si la tasa de resilver colapsa o los errores aumentan, deja de tratarlo como rutinario. Investiga errores de controlador,
cableado y carga. Considera programar trabajos pesados fuera de ventanas de resilver.

Task 8 (Linux + ZFS): Probar que el kernel está viendo errores de disco (no solo ZFS)

cr0x@server:~$ dmesg -T | egrep -i 'reset|i/o error|timeout|sense key' | tail -n 6
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] tag#231 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] Sense Key : Medium Error [current]
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] Add. Sense: Unrecovered read error
[Thu Dec 19 03:20:11 2025] blk_update_request: I/O error, dev sdf, sector 184467440
[Thu Dec 19 03:20:12 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 19 03:20:13 2025] ata7: hard resetting link

Qué significa: El SO ve errores de medio y resets de enlace. Esto ya no es “ZFS siendo quisquilloso.” Es hardware comportándose mal.

Decisión: Reemplaza el componente sospechoso. Si se repite en diferentes discos en la misma ruta, reemplaza la ruta
(HBA, backplane, expander, cable). No “monitores” un disco que arroja errores de medio durante un resilver.

Task 9 (Storage Spaces): Inspeccionar discos físicos y tipo de medio

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select FriendlyName,SerialNumber,MediaType,HealthStatus,OperationalStatus,Size | Format-Table -Auto"
FriendlyName SerialNumber MediaType HealthStatus OperationalStatus Size
------------ ------------ --------- ------------ ----------------- ----
PD01         Z4A0...      HDD       Healthy      OK                7.28 TB
PD02         Z4A1...      HDD       Healthy      OK                7.28 TB
PD03         Z4A2...      HDD       Warning      OK                7.28 TB
PD04         Z4A3...      HDD       Healthy      OK                7.28 TB

Qué significa: “Warning” en un disco físico es tu alarma temprana. Storage Spaces a menudo sigue funcionando mientras
el disco se degrada—hasta que no.

Decisión: Correlaciona con SMART/herramientas del proveedor y los registros de eventos. Si el disco está en “Warning,” planifica el reemplazo ahora, no después de que el disco virtual pase a “Degraded.”

Task 10 (Storage Spaces): Comprobar salud y resiliencia del disco virtual

cr0x@server:~$ powershell -NoProfile -Command "Get-VirtualDisk | Select FriendlyName,ResiliencySettingName,HealthStatus,OperationalStatus,Size,FootprintOnPool | Format-Table -Auto"
FriendlyName ResiliencySettingName HealthStatus OperationalStatus Size    FootprintOnPool
------------ --------------------- ------------ ----------------- ----    ---------------
VD-Data      Parity                Healthy      OK                40 TB   60 TB
VD-VMs       Mirror                Healthy      OK                12 TB   24 TB

Qué significa: La huella en pool de paridad es mayor que el tamaño lógico debido al layout y la sobrecarga de paridad. Esto también insinúa amplificación de escritura y costes de reconstrucción. El mirror es más predecible operativamente.

Decisión: Si tu carga es intensiva en escrituras o sensible a latencia, la paridad es un impuesto que pagarás a diario. Pon cargas calientes en mirror o mirror por niveles, y reserva paridad para datos más fríos con expectativas claras.

Task 11 (Storage Spaces): Verificar espacio libre del pool vs riesgo de provisión delgada

cr0x@server:~$ powershell -NoProfile -Command "Get-StoragePool -IsPrimordial $false | Select FriendlyName,HealthStatus,Size,AllocatedSize,FreeSpace | Format-List"
FriendlyName  : Pool01
HealthStatus  : Healthy
Size          : 58.2 TB
AllocatedSize : 54.9 TB
FreeSpace     : 3.3 TB

Qué significa: Solo quedan ~3.3 TB libres. Si tienes discos virtuales provisionados en delgado que crecen, puedes chocar con una parada total. Windows intentará avisarte. La producción intentará ignorarlo.

Decisión: Configura alertas en FreeSpace y aplica guardarraíles: o dejas de usar provisión delgada en sistemas críticos o mantienes margen real con una política (por ejemplo, nunca por debajo del 15–20%).

Task 12 (Storage Spaces): Identificar trabajos de reparación/optimización en curso que roban rendimiento

cr0x@server:~$ powershell -NoProfile -Command "Get-StorageJob | Select Name,JobState,PercentComplete,BytesProcessed,TimeRemaining | Format-Table -Auto"
Name                      JobState  PercentComplete BytesProcessed TimeRemaining
----                      --------  --------------- ------------- -------------
Repair Virtual Disk       Running   17              3.1 TB         05:12:33
Optimize Storage Pool     Running   42              9.8 TB         02:01:10

Qué significa: Trabajo de fondo está corriendo activamente. A menudo esta es la razón oculta por la que “el almacenamiento se volvió lento.” Los jobs son legítimos—pero compiten con tu carga.

Decisión: Si esto está en producción, programa estos trabajos o limita su impacto donde sea posible. Si las reparaciones se ejecutan con frecuencia, detente y pregúntate por qué: discos fallando, conexiones inestables o mala configuración.

Task 13 (Storage Spaces): Mapear un disco virtual a discos físicos subyacentes

cr0x@server:~$ powershell -NoProfile -Command "$vd=Get-VirtualDisk -FriendlyName 'VD-Data'; Get-PhysicalDisk -VirtualDisk $vd | Select FriendlyName,HealthStatus,OperationalStatus,Size | Format-Table -Auto"
FriendlyName HealthStatus OperationalStatus Size
------------ ------------ ----------------- ----
PD01         Healthy      OK                7.28 TB
PD02         Healthy      OK                7.28 TB
PD03         Warning      OK                7.28 TB
PD04         Healthy      OK                7.28 TB

Qué significa: Puedes vincular la abstracción a discos reales. Así evitas reemplazar la unidad equivocada en el chasis equivocado mientras todos observan.

Decisión: Reemplaza el disco en “Warning” y confirma que arranca el job de reparación. Si varios discos están en “Warning,” asume un dominio de fallo compartido (enclosure/backplane/firmware).

Task 14 (Storage Spaces / Windows): Leer el registro de eventos para señales específicas de almacenamiento

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 30 | Where-Object {$_.ProviderName -match 'Disk|Stor|Microsoft-Windows-Storage'} | Select TimeCreated,ProviderName,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           ProviderName                         Id LevelDisplayName Message
----------           ------------                         -- ----------------  -------
12/19/2025 03:21:10  Microsoft-Windows-StorageSpaces-Driver 312 Error            Physical disk has encountered an error and may fail.
12/19/2025 03:21:14  Disk                                 153 Warning          The IO operation at logical block address was retried.
12/19/2025 03:22:01  storahci                             129 Warning          Reset to device, \Device\RaidPort0, was issued.

Qué significa: Esto es el equivalente en Windows de la verdad en dmesg. Reintentos de disco y resets predicen cosas peores.

Decisión: Trata advertencias repetidas del estilo 153/129 como un incidente de hardware, no como un misterio de software. Comprueba firmware,
cableado, drivers del controlador y estabilidad de la alimentación.

Broma #2: Un pool de almacenamiento es como una reorganización corporativa—todo es “más resiliente” hasta que necesitas encontrar quién es el dueño del problema.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: Un incidente causado por una suposición incorrecta

Una compañía SaaS mediana ejecutaba servicios de archivos basados en Windows para artefactos de build internos y algunos shares de aplicaciones heredadas. Pasaron de un array RAID tradicional a Storage Spaces porque prometía una expansión más sencilla. La migración fue limpia, el pool estaba sano y les gustó la idea de la provisión delgada. “Añadiremos discos cuando los necesitemos.”

La suposición incorrecta: que las fallas por provisión delgada son gráciles. No lo son. La provisión delgada es un acuerdo con el futuro, y el futuro no firma SLAs.

Durante un trimestre, varios equipos aumentaron la retención de artefactos. Un par de entornos de prueba empezaron a volcar conjuntos de datos grandes en el share “temporalmente.” El espacio libre del pool se redujo lentamente. Existía monitorización, pero miraba el espacio libre del volumen dentro del disco virtual, no el espacio libre del pool de almacenamiento subyacente. El share aún tenía mucho espacio lógico libre, así que nadie se preocupó.

Entonces un job semanal provocó un pico de crecimiento, el pool se quedó sin capacidad física y las escrituras empezaron a fallar. No “lentas.” Fallando.
Aplicaciones que asumían semánticas tipo POSIX se comportaron mal. Algunas reintentaron agresivamente. Otras corrompieron sus propios metadatos. Un puñado se bloqueó por I/O.

La solución no fue heroica. Liberaron espacio, añadieron discos y estabilizaron el pool. La lección fue: debes monitorizar el pool, no solo el volumen. Y debes acordar una política de margen que la dirección no pueda negociar en una reunión.

Micro-historia 2: Una optimización que salió mal

Un equipo de plataforma de datos usaba ZFS en Linux para una carga mixta: blobs tipo objeto, extractos analíticos y unas pocas instancias de PostgreSQL. Recibieron quejas de rendimiento, y alguien sugirió añadir un NVMe rápido “como SLOG” porque leyó un post en un blog una vez. Instalaron un NVMe de consumo barato y pusieron logbias=latency en varios datasets.

Durante una semana, las cosas se sintieron más ágiles. No de forma uniforme, pero lo suficiente para declarar victoria. Luego el NVMe empezó a reportar errores de medio, seguidos de timeouts. El pool no explotó, pero la latencia de escrituras síncronas se disparó. Las bases de datos empezaron a quedarse colgadas. El incidente fue confuso porque los vdevs RAIDZ principales estaban sanos e iostat parecía “bien” a primera vista.

Habían optimizado lo incorrecto y creado una dependencia frágil. Un SLOG solo importa para escrituras síncronas, y solo si realmente estás haciendo escrituras sync. Peor: si añades un SLOG que no puede sostener escrituras seguras ante pérdida de energía, puedes convertir un crash ordenado en un show de recuperación horroroso.

El postmortem fue directo: no añadas un SLOG por nerviosismo. Mide tu tasa de escrituras síncronas. Usa un dispositivo empresarial con protección contra pérdida de energía si lo haces. Y recuerda que afinar un dataset por latencia puede penalizar a otro que quería rendimiento.

El resultado a largo plazo fue bueno. Retiraron el NVMe de consumo, ajustaron recordsize para las bases de datos, habilitaron compresión donde ayudaba y añadieron RAM. Fue menos emocionante que “añadir un disco mágico de caché,” y funcionó.

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

Una empresa de servicios financieros ejecutaba una plataforma NFS respaldada por ZFS para análisis internos. El equipo no era llamativo. Eran de los que programan scrubs, prueban restauraciones y se niegan a operar pools al 92% de capacidad. Otros equipos los llamaban paranoicos. Ellos lo llamaban “martes.”

Un mes, una carga por lotes empezó a fallar con errores de checksum durante lecturas. ZFS marcó un puñado de archivos con errores permanentes. El pool se mantuvo online, pero la evidencia fue inequívoca: algunos bloques estaban malos. El equipo no debatió si ZFS estaba “sobreactuando.” Lo trataron como un incidente de integridad de datos.

Porque ejecutaban scrubs regulares, tenían una línea base conocida buena y pudieron decir, con seguridad, que la corrupción era reciente. Rápidamente mapearon los errores a una ruta de disco específica y encontraron resets repetidos de enlace en logs del kernel. Reemplazaron la unidad y el cable como unidad. Restauraron los archivos afectados desde snapshots replicados a un segundo sistema.

Sin drama, sin outage prolongado. El triunfo mayor fue organizativo: pudieron probar que la plataforma detectó y contuvo la corrupción. Esa prueba importó más que el rendimiento bruto.

La práctica aburrida fue una combinación de disciplina de scrub, replicación y una cultura de creer en los contadores de error. Salvó el día porque redujo la incertidumbre. La incertidumbre es lo que convierte incidentes en folklore.

Guía rápida de diagnóstico

El objetivo no es “coleccionar datos.” El objetivo es identificar qué capa tiene la propiedad del cuello de botella: carga de trabajo, sistema de archivos, gestor de volúmenes,
dispositivo o transporte. Aquí hay un orden práctico de operaciones que funciona bajo presión.

Primero: confirma si es trabajo de corrección o carga de usuario

• ZFS: zpool status (¿scrub/resilver en progreso? ¿errores creciendo?)
• Storage Spaces: Get-StorageJob (¿repair/optimize corriendo?)

Si una reparación de fondo está activa, tu “problema” de rendimiento puede ser una característica de seguridad. Tu decisión pasa a ser programar y limitar—no ajustar perillas al azar.

Segundo: identifica si es presión de capacidad que se disfraza de latencia

• ZFS: zfs list, comprobar llenado del pool y síntomas de fragmentación
• Storage Spaces: Get-StoragePool FreeSpace; validar suposiciones de provisión delgada

Un sistema cercano a lleno no está solo sin espacio. Está sin opciones. La asignación se vuelve cara, las reparaciones más lentas y las colas más profundas.

Tercero: aislar el dispositivo o la ruta lenta

• ZFS/Linux: zpool iostat -v + dmesg para timeouts/resets
• Windows: logs de eventos + Get-PhysicalDisk en estado Warning

Si un disco está lento, tu “rendimiento del sistema de almacenamiento” está rehén de ese disco. Replázalo. No discutas con él.

Cuarto: validar las suposiciones de caché

• ZFS: estadísticas ARC, comportamiento de escrituras sync, presencia y salud del SLOG
• Storage Spaces: ajustes de tiering, configuración de write-back cache y si la caché está siendo thrasheada

Quinto: alinear la forma de I/O de la carga con el layout

Las escrituras aleatorias en layouts de paridad duelen. Bloques pequeños con recordsize grande desperdician ancho de banda. Las bases de datos odian sorpresas. Los shares de archivos odian tormentas de metadatos. Si la carga cambió, el almacenamiento “de repente empeoró” porque está haciendo exactamente lo que le pediste—solo que no lo que querías.

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

1) “Todo está sano” pero los usuarios reportan bloqueos

Síntoma: Las apps cuelgan en I/O, pero los dashboards muestran verde.

Causa raíz: Reparación/optimización de fondo consumiendo IOPS, o un disco individual con timeouts intermitentes mientras la abstracción aún informa “Healthy.”

Solución: Revisa Get-StorageJob / zpool status. Luego revisa logs del SO por timeouts. Reemplaza el disco/ruta que esté flappeando.

2) El disco virtual de paridad está “bien” pero las escrituras son dolorosamente lentas

Síntoma: Buen throughput de lectura, terribles escrituras aleatorias pequeñas.

Causa raíz: Penalización de escritura por paridad y comportamiento read-modify-write; caché no dimensionada para la carga; tiering no alineado con el patrón de escritura.

Solución: Usa mirror para datos intensivos en escritura, o tier con SSD y valida la tasa de aciertos de caché. No prometas latencia de paridad a equipos de bases de datos OLTP.

3) El pool ZFS se vuelve lento con el paso de los meses

Síntoma: Mismo hardware, misma carga (supuestamente), pero la latencia se incrementa gradualmente.

Causa raíz: Pool llenándose, fragmentación, más churn de metadatos, scrubs/resilvers que tardan más, misses de ARC aumentando conforme crece el working set.

Solución: Mantén margen, añade vdevs (no solo discos más grandes), ajusta propiedades de dataset y vigila la duración de scrubs como métrica de tendencia.

4) “Añadimos un disco de caché y empeoró”

Síntoma: Más dispositivos, peor latencia.

Causa raíz: Tipo de caché incorrecto (confusión SLOG vs L2ARC), SSD de consumo sin protección contra pérdida de energía, thrash de caché o dominio de fallo extra.

Solución: Mide escrituras sync antes de añadir SLOG. Usa dispositivos adecuados. Retira la caché si desestabiliza el sistema; la estabilidad vence al rendimiento teórico.

5) Provisión delgada en Storage Spaces golpea un muro de repente

Síntoma: Escrituras fallan, servicios se caen, volúmenes parecen “no llenos.”

Causa raíz: Capacidad física del pool agotada mientras los discos virtuales aún tienen espacio lógico libre.

Solución: Monitorea FreeSpace del pool, aplica política de margen y deja de tratar la provisión delgada como plan de capacidad.

6) ZFS reporta errores de checksum, pero SMART dice que el disco está bien

Síntoma: CKSUM incrementa en un dispositivo, pero atributos SMART lucen normales.

Causa raíz: Cable malo, puerto de expander malo, problemas de HBA o resets de enlace transitorios que corrompen transferencias.

Solución: Revisa logs del kernel. Reemplaza componentes de la ruta. Mueve bahías de disco. No aceptes “SMART está limpio” como veredicto cuando ZFS tiene prueba de corrupción.

7) Las reparaciones tardan una eternidad y el rendimiento se desploma durante las reconstrucciones

Síntoma: Rebuild/repair corre por días; la carga es inutilizable.

Causa raíz: Discos grandes y lentos, layouts de paridad, unidades SMR, demasiada carga concurrente o controles QoS pobres.

Solución: Prefiere mirrors para cargas sensibles a latencia, evita SMR en entornos con muchas reconstrucciones, programa ventanas de rebuild y ten repuestos/automatización listos.

Listas de comprobación / plan paso a paso

Si estás eligiendo entre ZFS y Storage Spaces

1. Decide qué temes más: corrupción silenciosa o complejidad operativa. Si temes la corrupción, ZFS es la respuesta por defecto.
2. Inventario de habilidades: si tu equipo vive en Windows y PowerShell, Storage Spaces puede ser más soportable—pero solo si te comprometes a aprender los cmdlets y logs profundos.
3. Ajusta el layout a la carga: paridad para frío, mirror para caliente. No negocies con la física.
4. Define política de margen: escríbela. Hazla cumplir con cuotas y alertas.
5. Define política de integridad: scrubs para ZFS; integrity streams/ajustes ReFS si estás en Windows (y prueba lo que realmente hacen en tu entorno).
6. Planifica ejercicios de fallo: practica reemplazo de discos, trabajos de reparación y flujos de restauración antes de necesitarlos.

Paso a paso: construir un despliegue ZFS sensato

1. Usa HBAs, no controladores RAID (modo IT / pass-through), para que ZFS vea los discos honestamente.
2. Elige topología de vdev intencionalmente: mirrors para IOPS y velocidad de reconstrucción; RAIDZ2 para capacidad con riesgo de reconstrucción aceptable.
3. Habilita compresión (a menudo zstd) salvo que tengas una razón específica para no hacerlo.
4. Configura propiedades de dataset por carga (recordsize, atime, política de sync con los ojos abiertos).
5. Programa scrubs y alerta sobre errores y cambios en la duración de scrubs.
6. Prueba restaurar desde snapshots/replicación. Un snapshot no es un backup hasta que lo hayas restaurado.
7. Mantén margen y planifica expansiones añadiendo vdevs, no esperando que discos más grandes arreglen mágicamente el dolor de asignación.

Paso a paso: hacer Storage Spaces menos misterioso

1. Decide mirror vs paridad por volumen según patrón de escritura, no por esperanzas de presupuesto.
2. Documenta el uso de provisión delgada y configura alertas de espacio libre del pool que despierten a humanos.
3. Instrumenta trabajos de fondo (Get-StorageJob) para correlacionar “está lento” con “está reparando.”
4. Rastrea señales de aviso en discos físicos y reemplaza temprano. No esperes a “Unhealthy.”
5. Valida firmware y drivers en staging; los drivers de almacenamiento no son lugar para actualizaciones YOLO.
6. Practica una reparación y mídela. Tu primera reparación no debería ser durante un outage de clientes.

Preguntas frecuentes (FAQ)

1) ¿ZFS es “más seguro” que Storage Spaces?

ZFS suele ser más seguro por defecto para la integridad de datos porque los checksums de extremo a extremo y los scrubs son de primera clase. Storage Spaces también puede ser seguro, pero debes configurar y monitorizar deliberadamente el comportamiento de integridad.

2) ¿Por qué la gente dice que ZFS necesita mucha RAM?

ZFS usa RAM para el cache ARC, que mejora el rendimiento y reduce I/O de disco. No “requiere” RAM absurda para funcionar, pero usará lo que le des. Si infra-provisionas RAM lo notarás en forma de latencia.

3) ¿La paridad en Storage Spaces siempre es lenta?

La paridad es inherentemente más cara para escrituras aleatorias pequeñas. Con escrituras secuenciales grandes, un buen diseño de caché/tier y una carga que encaje con el modelo, puede estar bien. Pero si prometes latencia de paridad a bases de datos OLTP, estás escribiendo tu propio informe de incidente.

4) ¿Cuál es el equivalente en ZFS de “virtual disk footprint on pool”?

ZFS muestra la asignación a nivel de pool y dataset (zfs list, zpool list). La sobrecarga de RAIDZ no está oculta, pero se expresa a través del espacio realmente asignado y el layout de paridad en lugar de un único número de “huella.”

5) ¿Puede Storage Spaces detectar bit rot como ZFS?

Puede, dependiendo del sistema de archivos y las configuraciones (comúnmente ReFS con características de integridad). En la práctica, muchas implementaciones no habilitan o validan esas características de extremo a extremo, por lo que la detección es menos consistente operativamente.

6) ¿Necesito un SLOG en ZFS?

Solo si tienes una carga significativa de escrituras síncronas y tus vdevs principales no pueden manejar la latencia. Mide primero. Si añades uno, usa un dispositivo diseñado para ello (la protección contra pérdida de energía importa).

7) ¿Cuál es el mayor “truco” con la provisión delgada?

Puedes quedarte sin capacidad física mientras aún tienes espacio lógico libre. Ese modo de fallo es abrupto y feo. La provisión delgada no es un plan de capacidad; es una táctica de utilización con requisitos estrictos de monitorización.

8) ¿Cómo decido mirror vs RAIDZ/paridad?

Si necesitas latencia predecible y reconstrucciones rápidas: mirror. Si necesitas eficiencia de capacidad y puedes tolerar escrituras más lentas y reparaciones más largas: RAIDZ2/paridad (con suficientes discos y margen). Si no estás seguro, mirror es la apuesta más segura operativamente.

9) ¿Cuál es más fácil de operar?

ZFS es más fácil de operar una vez que lo aprendes porque las señales son consistentes y locales. Storage Spaces es más fácil para empezar, pero puede volverse más difícil cuando depuras rendimiento o riesgo de capacidad a través de capas.

10) ¿Sobre qué debo alertar primero?

Para ZFS: cambios en zpool status, fallos de scrub, aumento de errores de checksum y umbrales de capacidad del pool. Para Storage Spaces: FreeSpace del pool, cualquier estado de HealthStatus distinto de “Healthy” en discos y jobs de almacenamiento de larga duración.

Siguientes pasos que realmente puedes hacer

Si ejecutas ZFS: haz que zpool status sea aburrido. Programa scrubs. Alerta sobre deltas de checksum. Rastrea duración de scrubs y tiempos de resilver como tendencias. Mantén margen. Y deja de fingir que un pool al 89% está “básicamente bien.”

Si ejecutas Storage Spaces: deja de confiar en la palabra “Healthy” sin contexto. Construye un script diario de salud alrededor de
Get-PhysicalDisk, Get-VirtualDisk, Get-StoragePool y Get-StorageJob. Alerta sobre FreeSpace del pool. Practica reemplazo de disco y reparación. Documenta exactamente para qué se usa la paridad y rehúsa poner cargas sensibles a latencia allí.

Si estás eligiendo: escoge la pila cuyos modos de fallo puedas explicar a un ingeniero cansado usando evidencia real. “Fácil” solo es fácil cuando se mantiene legible bajo estrés. Cuando se vuelve opaco, se vuelve caro.