Volúmenes sparse de ZFS: la trampa de la sobreasignación y cómo monitorizarla

Qué significan realmente los “volúmenes sparse” en ZFS

En ZFS, un zvol es un dispositivo de bloque respaldado por un dataset. Lo usas para VMs, LUNs iSCSI, bases de datos que requieren dispositivos de bloque crudos,
o cualquier sistema que piense en bloques, no en ficheros. Un zvol “sparse” está thin-provisioned: su volsize (el tamaño que presentas) puede ser mayor que
el espacio actualmente asignado en el pool.

Aquí está lo clave: sparse no significa libre. Significa “se asigna al escribir”. El pool sigue siendo el pool. Si los consumidores escriben lo suficiente,
ZFS debe asignar bloques reales. Cuando no puede, devuelve errores. Esos errores se propagan al sistema de ficheros invitado, a la base de datos o al hipervisor,
normalmente de la forma menos educada posible.

¿Por qué gustan los zvols sparse? Porque la alternativa es pesimismo: preasignar toda la capacidad para cada VM o LUN significa comprar discos antes de tiempo y
pasar años celebrando el espacio vacío que pagaste. La provisión delgada es pragmática. El problema es que también es una promesa que puedes romper.

Los dos números que debes separar en tu cabeza

• Tamaño lógico: lo que le dijiste al cliente que puede usar (volsize).
• Asignación física: lo que ZFS ha asignado realmente en el pool para ese zvol (más metadata, paridad, copias, etc.).

La sobreasignación ocurre cuando la suma de tamaños lógicos supera la capacidad física. No es inmediatamente incorrecto.
Se vuelve incorrecto cuando los patrones de escritura (o el calendario) hacen que esa promesa lógica venza.

La trampa de la sobreasignación: por qué falla tan de repente

La provisión delgada falla así: todo parece bien y de repente no lo está. Eso ocurre porque el consumo de almacenamiento es irregular.
Backups, trabajos por lotes semanales, ráfagas de logs, cadenas de snapshots de VM, compactación de bases de datos, reindexados y “migramos algo” asignan bloques reales rápidamente.
Pools que se mantienen al 70% durante meses pueden saltar al 95% en un día, y luego al 100% en una hora.

ZFS no es un sistema de ficheros “blando” respecto a la falta de espacio. Los pools casi llenos provocan fragmentación, dolor para el asignador y presión de metadata.
Cuando el pool se queda sin espacio de verdad, obtienes ENOSPC y luego fallos en cascada: discos de VM se vuelven de solo lectura, bases de datos entran en pánico, o el hipervisor no puede escribir
los logs necesarios para recuperarse. La provisión delgada es el acelerante; el verdadero incendio es la complacencia operativa.

También hay una sutileza: incluso si el pool muestra “algo de espacio libre”, aún puedes fallar asignaciones debido al slop space,
la fragmentación, efectos de recordsize/volblocksize y metadata que debe escribirse para mantener la consistencia.
El espacio libre no es un solo número. Es “espacio libre que es asignable en la forma y clase requeridas”.

Broma #1: La provisión delgada es como pedir pantalones “cuando algún día quepa en ellos”. Ese día llega a las 2 a.m., y tu cinturón es el pager.

Qué se rompe primero en la vida real

• Sistemas de ficheros invitados ven errores de E/S. El journaling ayuda hasta que no lo hace.
• Bases de datos reciben escrituras parciales o no pueden extender archivos, y luego entran en recuperación en el peor momento.
• Hipervisores pueden pausar VMs, marcar discos como fallados o fallar snapshots.
• Replicación puede estancarse porque no puede escribir buffers de recepción o snapshots nuevos.
• El propio ZFS lucha por liberar espacio si necesitas borrar snapshots pero no puedes escribir actualizaciones de metadata de forma fiable.

Un pool que supera ~80–85% no es una falla moral. Es una señal. Puedes operar más alto si conoces la carga de trabajo y eres disciplinado.
Pero con provisión delgada, la disciplina significa monitorización y margen, no optimismo y buenas vibras.

Hechos interesantes y contexto (lo que explica la rareza)

1. ZFS introdujo el almacenamiento en pool como idea principal, así que “sistema de ficheros lleno” se convirtió en “pool lleno”. Eso desplaza los dominios de fallo desde un único punto de montaje a todo.
2. La provisión delgada se popularizó en SAN empresariales mucho antes de que los zvols de ZFS fueran comunes; ZFS heredó tanto los beneficios como los filos cortantes.
3. La contabilidad de espacio en ZFS es intencionalmente conservadora en varios lugares (slop space, reservaciones de metadata) para prevenir interbloqueos catastróficos.
4. Copy-on-write significa que las sobreescrituras asignan primero bloques nuevos, y luego liberan los antiguos. Los pools casi llenos castigan las cargas de trabajo que actualizan en sitio.
5. Los snapshots no “usan espacio” al crearse, pero fijan bloques antiguos. Los borrados y sobreescrituras se convierten en nuevas asignaciones en vez de reutilización.
6. La compresión cambia las matemáticas de la sobreasignación porque logicalused puede ser mucho mayor que lo físicamente usado—hasta que los datos no son compresibles (hola, backups cifrados).
7. La sobrecarga de paridad en RAIDZ está moldeada por la carga: escrituras aleatorias pequeñas pueden amplificar la asignación por el padding y la alineación de registros (varía según la implementación y ashift).
8. Las clases de asignación especiales (special vdevs) pueden mover metadata/pequeños bloques fuera de discos giratorios, pero crean otro precipicio de capacidad si son demasiado pequeños.
9. El soporte de Discard/TRIM tardó en madurar en el ecosistema de virtualización; invitados que no emiten discard hacen que ZFS no pueda aprender que los bloques son libres.

Mecánica que importa: volsize, referenced, logicalused y los bloques que no puedes evitar

zvols sparse: las propiedades que deciden tu destino

ZFS te da un puñado de palancas. La mayoría de la gente solo tira de una (crear sparse) e ignora el resto. Así es como acabas con un pool “misteriosamente” lleno.

• volsize: el tamaño expuesto del dispositivo de bloque. Esta es la promesa.
• refreservation: espacio garantizado para el dataset (zvol). Esta es la palanca “no sobreasignaremos esta porción”.
• reservation: concepto similar para sistemas de ficheros; para zvols normalmente se usa refreservation.
• volblocksize: granularidad de asignación para el zvol; impacta el rendimiento y la eficiencia de espacio.
• compression: puede ampliar el margen dramáticamente—hasta que tus datos no sean compresibles.
• sync: cómo ZFS maneja escrituras síncronas; cambiarlo puede alterar el rendimiento y el comportamiento ante fallos.

Términos de contabilidad de espacio que debes leer rápido

Para zvols, USED y afines en zfs list son fáciles de malinterpretar. Añade estas columnas y el mundo se aclara:

• used: espacio real consumido en el pool (incluyendo metadata y copias según la vista).
• referenced: espacio accesible por este dataset en su cabeza (sin contar snapshots).
• logicalused: bytes lógicos sin comprimir referenciados (útil para comprobar la realidad de la ratio de compresión).
• logicalreferenced: referenced lógico en la cabeza del dataset.
• usedbysnapshots: espacio fijado por snapshots; el culpable de “por qué el borrado no libera espacio”.

La parte que nadie presupone: metadata, fragmentación y “espacio que no puedes gastar”

ZFS necesita espacio para respirar. Cuando te acercas al lleno, el asignador tiene menos opciones, los metaslabs se fragmentan,
y las escrituras se ralentizan. Esa desaceleración en sí puede activar más escrituras: timeouts, reintentos, crecimiento de logs, archivos de recuperación por caídas.
Es un bucle de retroalimentación con sentido del humor que no compartirás.

Una idea de fiabilidad relevante viene de la cultura de ingeniería más que de detalles específicos de ZFS:
La esperanza no es una estrategia. (idea parafraseada atribuida a menudo a formación en operaciones y fiabilidad)

Si ejecutas zvols sparse sin reservations, estás gestionando un sistema donde la esperanza es literalmente el modelo de capacidad.
Puedes hacerlo mejor.

Señales de monitorización que realmente predicen fallos

Monitorizar la provisión delgada no es “alertar cuando el pool esté al 90%”. Eso es una alerta y llega tarde.
Quieres un pequeño conjunto de señales que expliquen tanto la capacidad como la tasa de cambio, además de “cosas que hacen imposible la recuperación”.

Señales a rastrear (y por qué)

• Porcentaje de asignación del pool (zpool list): la grande y obvia. Rastrea la tendencia, no solo el valor actual.
• Espacio libre por clase (zpool list -v en algunas plataformas; también zpool status): special vdevs y log vdevs pueden tener sus propios precipicios.
• Espacio de snapshots (usedbysnapshots): un pool puede estar “lleno” porque la retención lo está consumiendo silenciosamente.
• Razón de sobreasignación: suma de volsize de zvols dividida por el tamaño físico del pool (y/o por “usable seguro”).
• Datos sucios / presión de txg (zfs-stats u equivalentes de plataforma): los picos a menudo correlacionan con ráfagas de escritura grandes.
• Indicadores de amplificación de escritura: IOPS altos con rendimiento moderado, latencia en aumento y fragmentación del asignador (histogramas de metaslab).
• Deriva de ratio de compresión: cuando nuevas cargas son incomprimibles, la curva de consumo de pool se inclina hacia arriba.
• Efectividad del discard: si los invitados emiten discard y si eso resulta en que ZFS libere espacio con el tiempo.

Umbrales de alerta que no mienten (mucho)

Usa alertas escalonadas, no un gran precipicio:

• 75%: “aviso”. Verifica la tendencia de crecimiento y la retención de snapshots. Comienza a planear.
• 85%: “acción”. Congela snapshots no esenciales, valida espacio para replicación, asegura que los borrados realmente reclaman.
• 90%: “cambio de modo”. Deja de crear nuevos volúmenes thin. Mueve cargas. Añade vdevs o reduce la retención. Trátalo como prevención de incidentes.
• 95%: “incidente”. Ahora pagas la tasa de fragmentación y corres riesgo de fallo de asignación. Ejecuta un runbook, no un debate.

Estos umbrales dependen de la carga y del layout de vdevs. RAIDZ más escrituras aleatorias necesita más margen que mirrors con escrituras mayormente secuenciales.
Pero si estás thin provisioning y no conoces la forma de tu carga, elige umbrales conservadores y disfruta de dormir.

Tareas prácticas: comandos, significado de salidas, decisiones

Esta sección es intencionalmente operacional. El punto no es admirar a ZFS. El punto es saber qué hacer a las 3 a.m.
Cada tarea incluye un comando ejecutable, qué significa la salida y qué decisión tomar.

Tarea 1: Comprobar capacidad y salud del pool rápidamente

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  21.8T  18.9T  2.90T        -         -    41%    86%  1.00x  ONLINE  -

Qué significa: CAP 86% está en la zona de “acción”. FRAG 41% sugiere que viene dolor para el asignador.

Decisión: Detener escrituras no esenciales (tormentas de snapshots, migraciones). Inicia revisión de snapshots/retención y plan de capacidad ahora.

Tarea 2: Confirmar que no hay dispositivos fallando mientras persigues “fantasmas de espacio”

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 09:12:44 with 0 errors on Sun Dec 22 09:12:55 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     1
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDGZ-...   ONLINE       0     0     0

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

        tank/vmstore/zvol-104-disk-0

Qué significa: Hay un error de checksum asociado a un zvol específico. No es un problema de capacidad, pero puede disfrazarse como tal.

Decisión: Triage de integridad de datos por separado: verifica el disco invitado, resultados de scrub, considera reemplazar el disco y restaurar la VM afectada si es necesario.

Tarea 3: Listar zvols y detectar el panorama de sobreasignación

cr0x@server:~$ zfs list -t volume -o name,volsize,used,referenced,logicalused,refreservation -r tank/vmstore
NAME                       VOLSIZE  USED   REFER  LUSED  REFRESERV
tank/vmstore/vm-101-disk-0   500G   412G   401G   603G          none
tank/vmstore/vm-102-disk-0     2T   1.31T  1.28T  1.28T         none
tank/vmstore/vm-103-disk-0     1T    74G    72G    92G          none
tank/vmstore/vm-104-disk-0     4T   3.61T  3.55T  3.55T         none

Qué significa: Estos son sparse (sin refreservation). Las promesas de tamaño lógico son grandes. Hay compresión (vm-101 muestra logical > physical).

Decisión: Si esto es producción, elige: establecer refreservation para zvols críticos, o aplicar un estricto headroom de pool con alertas y gestión de capacidad.

Tarea 4: Calcular la “capacidad prometida” (suma de volsize)

cr0x@server:~$ zfs list -H -p -t volume -o volsize -r tank/vmstore | awk '{s+=$1} END{printf("total_volsize_bytes=%d\n",s)}'
total_volsize_bytes=8246337208320

Qué significa: Has prometido ~8.2 TB a invitados en este subtree. Ese número por sí solo no es malvado; es contexto.

Decisión: Compáralo con el espacio usable del pool (tras paridad, slop space policy y crecimiento). Define un máximo ratio de overcommit y hazlo cumplir.

Tarea 5: Ver la presión de snapshots para un árbol de datasets

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbydataset,usedbychildren -r tank/vmstore | head -n 8
NAME                 USED  USEDSNAP  USEDDS  USEDCH
tank/vmstore         6.12T   2.04T    4.01T   77.6G
tank/vmstore/vm-101  622G    211G     401G    9.6G
tank/vmstore/vm-102  1.53T   243G     1.28T   12.4G
tank/vmstore/vm-103  119G    42.1G     72G    4.9G
tank/vmstore/vm-104  3.85T   1.52T    3.55T   18.6G

Qué significa: 2 TB en snapshots no es “gratis”. Está asignado y fijado. Borrar dentro de los invitados no reclamará eso.

Decisión: Si la capacidad es ajustada, ajusta la retención. Elimina snapshots estratégicamente (más antiguos, mayores deltas), y confirma dependencias de replicación primero.

Tarea 6: Identificar rápidamente los mayores consumidores de espacio

cr0x@server:~$ zfs list -o name,used,usedbysnapshots -s used -r tank/vmstore | tail -n 6
tank/vmstore/vm-103   119G   42.1G
tank/vmstore/vm-101   622G    211G
tank/vmstore/vm-102  1.53T    243G
tank/vmstore/vm-104  3.85T   1.52T

Qué significa: vm-104 está cargando un enorme lastre de snapshots.

Decisión: Si necesitas recuperar rápido, las cargas con muchos snapshots son las más “recuperables” —tras validar requisitos de negocio/backup.

Tarea 7: Ver la realidad de la compresión (y detectar el momento “el backup cifrado lo arruinó”)

cr0x@server:~$ zfs get -H -o name,property,value compression,compressratio -r tank/vmstore | head
tank/vmstore             compression    zstd
tank/vmstore             compressratio  1.24x
tank/vmstore/vm-101      compression    zstd
tank/vmstore/vm-101      compressratio  1.46x
tank/vmstore/vm-102      compression    zstd
tank/vmstore/vm-102      compressratio  1.02x

Qué significa: vm-102 es básicamente incomprimible. Si crece, consumirá espacio crudo casi 1:1.

Decisión: No cuentes ahorros de compresión para cargas que cifran en reposo dentro del invitado o almacenan blobs ya comprimidos. Planifica la capacidad como si fuera 1.0x.

Tarea 8: Comprobar reservation/refreservation (a.k.a. “quién puede hundir el barco”)

cr0x@server:~$ zfs get -o name,property,value -r tank/vmstore | egrep 'refreservation|reservation' | head -n 12
tank/vmstore             reservation      none
tank/vmstore             refreservation   none
tank/vmstore/vm-101      reservation      none
tank/vmstore/vm-101      refreservation   none
tank/vmstore/vm-102      reservation      none
tank/vmstore/vm-102      refreservation   none

Qué significa: Nadie tiene espacio garantizado. Eso significa que el último escritor gana hasta que el pool pierde.

Decisión: Para volúmenes “no deben fallar” (bases de datos, plano de control, identidad), establece refreservation para que puedan seguir escribiendo incluso bajo presión.

Tarea 9: Establecer un refreservation para un zvol crítico (y entender la consecuencia)

cr0x@server:~$ sudo zfs set refreservation=600G tank/vmstore/vm-101-disk-0
cr0x@server:~$ zfs get -H -o name,property,value refreservation tank/vmstore/vm-101-disk-0
tank/vmstore/vm-101-disk-0  refreservation  644245094400

Qué significa: ZFS ahora reserva ~600G para este volumen. El espacio libre del pool disminuye en consecuencia.

Decisión: Así evitas que cargas críticas sean asfixiadas por un trabajo descontrolado de otro. Úsalo intencionalmente; reduce la flexibilidad.

Tarea 10: Comprobar ashift y layout de vdev (las matemáticas de capacidad dependen de ello)

cr0x@server:~$ zdb -C tank | egrep 'ashift|raidz|mirror' | head -n 20
        ashift: 12
            type: 'raidz'
            nparity: 2

Qué significa: ashift 12 implica sectores de 4K. Existe sobrecarga de paridad RAIDZ2. Escrituras pequeñas pueden amplificarse.

Decisión: Si ya vas justo de espacio, cambiar patrones de carga (más escrituras aleatorias, bloques más pequeños) puede acelerar el consumo y la fragmentación. Tenlo en cuenta en la evaluación de riesgos.

Tarea 11: Inspeccionar fragmentación de espacio e histogramas de metaslab

cr0x@server:~$ sudo zdb -mm tank | head -n 40
Metaslab 0:
        size     1090519040
        alloc    1019215872
        free       71303168
        free segments: 142
        histogram:
        000: ------------------------------------------------------------
        001: *******************                                         19
        002: *****************************                               29
        003: ********************                                        20

Qué significa: Muchos segmentos libres pequeños significan “existe espacio libre pero está picado”. La asignación se vuelve más lenta y puede fallar para necesidades contiguas grandes.

Decisión: Trata la alta fragmentación + alta capacidad como un factor de riesgo multiplicador. Crea margen liberando espacio y evitando churn (snapshots, reescrituras).

Tarea 12: Confirmar que el guest tiene discard habilitado (la provisión delgada sin discard es una mentira)

cr0x@server:~$ lsblk -D
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0
sdb           0      512B       2G         0

Qué significa: Los dispositivos de bloque exponen la granularidad de discard. Eso es necesario pero no suficiente.

Decisión: Asegura que el hipervisor pase discard/TRIM y que el sistema de ficheros invitado lo emita (opciones de montaje, temporizador fstrim). Si no, los borrados no reclamaran.

Tarea 13: Observar si liberar datos realmente reclama en el host

cr0x@server:~$ zfs get -H -o name,property,value written tank/vmstore/vm-101-disk-0
tank/vmstore/vm-101-disk-0  written  103215702016

Qué significa: written puede ayudar a estimar el churn reciente. Si los invitados “eliminaron mucho” pero used no baja, sospecha snapshots o discard ausente.

Decisión: Si los snapshots fijan bloques, discard no ayudará. Si los snapshots son mínimos, habilita discard de extremo a extremo y ejecuta trims.

Tarea 14: Encontrar datasets con grandes deltas de snapshot (candidatos de recuperación rápida)

cr0x@server:~$ zfs list -t snapshot -o name,used,referenced -s used -r tank/vmstore | tail -n 5
tank/vmstore/vm-104@auto-2025-12-20  188G  3.55T
tank/vmstore/vm-104@auto-2025-12-21  201G  3.55T
tank/vmstore/vm-104@auto-2025-12-22  214G  3.55T
tank/vmstore/vm-102@auto-2025-12-22   61G  1.28T
tank/vmstore/vm-101@auto-2025-12-22   49G   401G

Qué significa: Snapshots con gran USED consumen muchos bloques únicos. Borrar uno puede reclamar espacio significativo.

Decisión: Si la replicación lo permite, borra los snapshots más grandes/antiguos primero. Si la replicación depende de ellos, necesitas otro plan (ampliar capacidad o ajustar replicación).

Tarea 15: Cuando estés cerca del lleno, comprobar el impacto del slop space

cr0x@server:~$ zfs get -H -o property,value slop_space tank
slop_space  12884901888

Qué significa: ZFS reserva algo de espacio efectivamente fuera de límites para reducir escenarios de “el pool está tan lleno que no puede funcionar”.

Decisión: No planees usar los últimos GB/TB. Planifica nunca ver 100% fuera de un laboratorio. Si estás tocando slop space, ya llegaste tarde.

Tarea 16: Comprobar si siquiera puedes borrar (a veces no puedes, y esa es la historia de terror)

cr0x@server:~$ sudo zfs destroy tank/vmstore/vm-104@auto-2025-12-20
cannot destroy 'tank/vmstore/vm-104@auto-2025-12-20': out of space

Qué significa: Estás en la zona de “no se puede liberar espacio porque liberar espacio necesita espacio” (las operaciones de metadata aún requieren asignaciones).

Decisión: Detén todas las escrituras, exporta datasets no críticos si es posible, añade espacio (adjunta temporalmente un vdev) o libera espacio desde otro pool vía send/receive. Esto es un incidente.

Broma #2: Un pool al 99% es como una reunión que “solo durará cinco minutos”. Todos saben lo que pasa después.

Guion de diagnóstico rápido

Cuando un entorno con provisión delgada se pone raro, la gente discute sobre “almacenamiento” como si fuera el clima. No lo hagas.
Ejecuta una secuencia corta que te diga: ¿nos falta espacio, integridad o rendimiento?

Primero: confirma el modo de fallo (capacidad vs integridad vs rendimiento)

1. Capacidad y fragmentación del pool: zpool list. Si CAP > 85% y FRAG en aumento, trátalo como incidente por presión de capacidad aunque no esté “lleno”.
2. Salud del pool: zpool status -v. Si existen errores, arregla la integridad antes de perseguir la “matemática de la provisión delgada”.
3. Pinning por snapshots: zfs list -o usedbysnapshots en el árbol relevante. Si el uso por snapshots es grande, los borrados en invitados no ayudarán.

Segundo: localiza el consumidor y la tasa de crecimiento

1. Top datasets/zvols por USED: zfs list -s used.
2. Top snapshots por USED: zfs list -t snapshot -s used.
3. Indicadores de churn: zfs get written en los sospechosos; correlaciona con horarios de trabajos y actividad de VMs.

Tercero: decide si puedes reclamar o debes expandir

1. Si es recuperable: borra snapshots (con cuidado), reduce retención, habilita discard, compacta dentro de los invitados donde realmente resulte en bloques liberados.
2. Si no es recuperable rápido: añade capacidad (nuevos vdevs) o mueve cargas fuera del pool; no intentes heroísmos en un pool al 95–100%.
3. Protege cargas críticas: aplica refreservation para zvols esenciales antes de comenzar a borrar las cosas equivocadas.

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

1) “Los invitados muestran espacio libre, pero las escrituras fallan con ENOSPC”

Síntoma: El sistema de ficheros de la VM muestra espacio, las aplicaciones fallan, logs del hipervisor “No space left on device”.

Causa raíz: El pool ZFS está lleno (o efectivamente lleno por slop space / fragmentación). El invitado no ve la saturación del host hasta que las escrituras fallan.

Solución: Libera espacio del pool inmediatamente (borra snapshots, mueve datasets), añade capacidad y luego aplica límites de headroom y opcionalmente refreservation para discos críticos.

2) “Borrar archivos en el invitado no libera espacio en el pool”

Síntoma: El uso en el invitado baja; USED en ZFS no baja.

Causa raíz: Snapshots fijan bloques, o discard no funciona de extremo a extremo, o el sistema de ficheros del invitado no emite trim.

Solución: Comprueba usedbysnapshots. Si está alto, borra/expira snapshots. Si es bajo, habilita discard en hipervisor + invitado y programa fstrim periódico.

3) “El pool está al 88% y todo está lento”

Síntoma: Picos de latencia, pausas de VM, escrituras síncronas lentas.

Causa raíz: Fragmentación y contención del asignador en niveles altos de llenado; copy-on-write amplifica las sobreescrituras pequeñas; RAIDZ puede magnificar escrituras aleatorias pequeñas.

Solución: Crea margen (objetivo <80–85%), reduce churn (snapshots, reescrituras frecuentes), afina tamaños de bloque cuando sea apropiado y considera cambios de layout para la próxima arquitectura (mirrors para cargas IOPS-intensas).

4) “Hicimos thin provisioning porque la compresión nos ahorraría”

Síntoma: La curva de crecimiento del pool se acelera de repente.

Causa raíz: Nuevos datos son incomprimibles (backups cifrados, medios, archivos ya comprimidos). Las asunciones de ratio de compresión se volvieron fantasía.

Solución: Rastrea la deriva de compressratio y planifica con 1.0x para cargas no confiables. Mueve datos incomprimibles a pools o tiers separados.

5) “La eliminación de snapshots tarda una eternidad y el espacio no vuelve”

Síntoma: Destruir snapshots es lento; el pool sigue presionado.

Causa raíz: Alta fragmentación y cadenas masivas de snapshots hacen que las liberaciones sean costosas; además el espacio vuelve gradualmente conforme completan las actualizaciones de metadata.

Solución: Borra snapshots en lotes fuera de pico, evita cadenas gigantes, mantén headroom y considera revisar la estrategia de backups (menos snapshots de larga vida, más retención incremental en otro sitio).

6) “No podemos borrar snapshots porque el pool está sin espacio”

Síntoma: zfs destroy devuelve out-of-space.

Causa raíz: El pool está tan lleno que las operaciones de metadata no pueden asignar; estás más allá de la “limpieza” y en la fase de “estabilizar”.

Solución: Detén las escrituras, añade capacidad temporal (un nuevo vdev es la vía limpia) o evacúa datasets usando send/receive si es posible. Luego implementa techos operativos estrictos.

Tres mini-historias corporativas desde las trincheras de la provisión delgada

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

Una compañía SaaS mediana operaba un cluster de virtualización con zvols respaldados por ZFS. El equipo de almacenamiento estaba cómodo con la provisión delgada porque “las VMs nunca llenan sus discos”.
Eso fue verdad, hasta que dejó de serlo.

En un trimestre, finanzas pidió retenencia de logs más larga para auditoría. El equipo de aplicaciones cumplió aumentando la verbosidad de logs y guardando más historial en los mismos discos de VM.
Nadie se lo dijo a almacenamiento. Nadie pensó que debía hacerlo.

Dos semanas después, el pool alcanzó altos 80s. El rendimiento se volvió gomoso, pero nada alertó fuerte. Entonces entró una ventana de mantenimiento: snapshots de VM para backups, más una actualización de aplicación que reescribió grandes datasets.
Copy-on-write hizo lo suyo: las sobreescrituras necesitaron asignaciones nuevas. El pool pasó de “incómodo” a “lleno” más rápido de lo que la monitorización pudo alertar.

El primer síntoma visible no fue “pool lleno”. Fue que escrituras de base de datos fallaron en un invitado, seguidas de bucles de caída y errores “filesystem read-only”.
El canal de incidentes se llenó de teorías: problemas SAN, bug de kernel, “quizá el hipervisor está inestable”.

La solución fue aburrida: borrar snapshots viejos, reducir retención y añadir un vdev. La lección no fue “la provisión delgada es malvada”.
La lección fue que la provisión delgada es un contrato, y el contrato nunca se redactó.

Mini-historia 2: La optimización que se volvió en contra

En una gran empresa, un equipo de plataforma quiso mejor eficiencia de almacenamiento. Habilitaron snapshotting agresivo—cada hora por una semana, diario por un mes—en datasets zvol de VM.
Las gráficas se veían bien: rollback rápido, restores fáciles, menos tickets de backup.

Luego introdujeron una nueva carga de CI con muchas VMs efímeras. Esas VMs escribían, borraban, reescribían y repetían. Dentro de los invitados, los ficheros iban y venían constantemente.
En ZFS, con snapshots, borrar no significa “liberar”. Significa “liberar más tarde, si nadie referencia los bloques antiguos”. Los snapshots referenciaban todo.

El uso de espacio creció de forma constante, pero el equipo lo justificó: “Los snapshots valen la pena”. El pool se mantuvo bajo 80% por un tiempo.
La trampa fue que la fragmentación subía y la cadena de snapshots convertía cada sobreescritura en asignación neta nueva.

Cuando el pool cruzó los altos 80s, la latencia explotó. Los trabajos de CI se ralentizaron, lo que causó timeouts. Los timeouts causaron reintentos. Los reintentos causaron más escrituras.
No era solo presión de capacidad; era una espiral de amplificación de escrituras impulsada por una “optimización” que nadie revisó.

Lo arreglaron separando clases de carga: las VMs de CI se movieron a un pool con otra política de snapshots (retención corta), y las snapshots “golden rollback” se reservaron solo para sistemas con estado de larga vida.
No quitaron el snapshotting. Lo hicieron intencional.

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

Una compañía sanitaria ejecutaba zvols ZFS para sistemas críticos. Su responsable de almacenamiento insistió en dos reglas:
mantener la utilización del pool bajo un techo duro y establecer refreservation en el puñado de volúmenes que nunca deben fallar en escritura.
No fue popular. Las reservaciones hacen que los pools parezcan “más pequeños”, y los dashboards aman los grandes números de espacio libre.

Durante un mes cierre rutinario, un sistema de reporting se volvió loco y empezó a generar enormes ficheros intermedios en su disco de VM.
Llenó lo que se le había prometido. En una configuración thin sin guardarraíles, eso habría sido problema de todos.

En cambio, la VM de reporting mostró errores de E/S y dejó de crecer. Aun así fue desagradable, pero quedó contenido.
Los volúmenes de base de datos y los servicios de identidad mantuvieron su espacio garantizado y siguieron saludables.

El equipo de operaciones tuvo tiempo para responder: ampliaron el disco de reporting correctamente, reequilibraron la retención y añadieron capacidad según el plan, no en pánico.
Nada hizo titulares. Ese es el punto.

Listas de verificación / plan paso a paso

Lista A: Antes de habilitar zvols sparse en producción

1. Define una política de overcommit: ratio máximo, qué inquilinos pueden sobreasignar y qué ocurre cuando se cruzan umbrales.
2. Elige objetivos de headroom: un techo duro para CAP del pool (comúnmente 80–85% para cargas mixtas; más conservador para RAIDZ + escrituras aleatorias).
3. Decide qué volúmenes son “deben escribir”: establece refreservation para esos y acepta la pérdida visible de espacio libre como coste de fiabilidad.
4. Retención de snapshots por clase: no apliques la misma retención a discos efímeros de CI y a bases de datos.
5. Plan de Discard/TRIM: confirma que hipervisor e invitados lo soportan; programa fstrim o equivalente.
6. Monitorización y alertas: CAP del pool, FRAG, uso de snapshots, deriva de compressratio y alertas de tasa de cambio.

Lista B: Revisión operativa semanal (15 minutos, ahorra un fin de semana)

1. Comprobar zpool list para tendencias de CAP y FRAG.
2. Comprobar uso de snapshots más alto con zfs list -o usedbysnapshots.
3. Revisar datasets/zvols de mayor crecimiento: zfs list -s used.
4. Validar que los scrubs se completen y estén limpios: zpool status.
5. Detectar cambios en compressratio entre datasets principales.
6. Confirmar que los targets de replicación también tienen headroom (la provisión delgada en ambos extremos es cómo obtienes desastres sincronizados).

Lista C: Cuando el pool alcanza 85% (trátalo como un incidente controlado)

1. Congela el churn: pausa migraciones masivas, suspende jobs de snapshots no esenciales, detén pipelines de prueba que golpeen el disco.
2. Identifica espacio recuperable: snapshots más grandes, datasets con mucho peso de snapshots.
3. Confirma la ruta de discard: si dependes de reclamación por borrado, verifica que sea factible.
4. Protege escritores críticos: aplica refreservation si falta, antes de que el pool empeore.
5. Decide expansión vs recuperación: si no puedes reclamar suficiente de forma segura, programa la adición de capacidad inmediatamente.

Lista D: Cuando el pool alcanza 95% (deja de improvisar)

1. Detén las escrituras donde sea posible (throttles de aplicación, pausa creación de VMs, detén ráfagas de snapshots de backup).
2. No lances “scripts de limpieza” al azar; borrarás lo fácil, no lo efectivo.
3. Prioriza borrar snapshots grandes que sea seguro eliminar (valida replicación y requisitos de restauración).
4. Prepárate para añadir un vdev. Esto suele ser la salida segura y más rápida.
5. Tras estabilizar: postmortem de la política de overcommit e implementa alertas de tasa de cambio.

Preguntas frecuentes

1) ¿Los zvols sparse son lo mismo que “thin provisioning” en un SAN?

Conceptualmente, sí: presentas más capacidad lógica de la que has asignado físicamente. Operacionalmente, ZFS añade copy-on-write, snapshots y asignación en pool,
lo que puede hacer los modos de fallo más agudos si vas caliente en espacio.

2) ¿La sobreasignación siempre es mala?

No. La sobreasignación es una herramienta. Se vuelve mala cuando no la mides, no la limitas y no mantienes headroom para ráfagas y comportamiento copy-on-write.
Si no puedes explicar tu ratio de overcommit y tu plan de recuperación, no estás sobreasignando—estás apostando.

3) ¿Debo usar refreservation en cada zvol?

Normalmente no. Reservar todo derrota la virtud de la provisión delgada. Úsalo en volúmenes críticos donde la falla de escritura sea inaceptable (bases de datos, plano de control, servicios compartidos),
y confía en headroom + alertas para el resto.

4) ¿Por qué ZFS se vuelve lento cuando el pool está casi lleno?

Porque a los asignadores les gusta tener opciones. Los pools casi llenos tienen menos segmentos libres, mayor fragmentación y las sobreescrituras copy-on-write requieren nuevas asignaciones.
En RAIDZ, las escrituras aleatorias pequeñas pueden añadir sobrecarga extra. El resultado es inflación de latencia y colapso de throughput.

5) ¿Puedo confiar en borrar datos en los invitados para reclamar espacio en el pool?

Solo si dos cosas son ciertas: los snapshots no fijan esos bloques y discard/TRIM funciona de extremo a extremo.
Sin discard, el host a menudo no puede saber que los bloques están libres. Con snapshots, no son libres aunque el invitado los borre.

6) ¿Cuál es la forma más segura de reclamar espacio rápidamente?

Borrar snapshots grandes y antiguos con significativo USED suele ser la reclamación más predecible—suponiendo que hayas validado replicación y requisitos de restauración.
Borrar ficheros al azar dentro de invitados es menos predecible a menos que sepas que discard es efectivo y que los snapshots no te mantienen de rehén.

7) ¿La compresión y la deduplicación cambian el riesgo de sobreasignación?

La compresión puede ayudar mucho, pero depende de la carga y puede cambiar con el tiempo. La dedup puede ser peligrosa operacionalmente por presión de memoria y complejidad;
tampoco arregla la verdad fundamental de que las escrituras requieren bloques físicos. Modela el riesgo como si la compresión pudiera caer a 1.0x.

8) ¿Cómo configuro alertas específicas para provisión delgada?

Alerta sobre CAP del pool con múltiples umbrales, rastrea crecimiento de uso de snapshots y controla el ratio de overcommit (suma de volsize vs pool usable).
Añade alertas de tasa de cambio: “pool used +5% en 1 hora” captura ráfagas que los umbrales estáticos pierden.

9) ¿Cuál es un ratio de overcommit razonable?

No hay un número universal. Para flotas VM predecibles con buena higiene, 1.5–2.0x puede ser tolerable.
Para cargas mixtas con muchos snapshots y equipos desconocidos, mantenlo más cerca de 1.0–1.2x o aplica reservations en subconjuntos críticos.

10) ¿Alguna vez es aceptable operar al 90%?

A veces, por un periodo corto, con cargas conocidas, mirrors, bajo churn y un plan de recuperación ensayado. En general, 90% es donde ZFS empieza a cobrar intereses.
Si estás thin provisioning y vives al 90%, estás eligiendo drama.

Conclusión: siguientes pasos que evitan el pager

Los zvols sparse no son el villano. El villano son las promesas sin gestión. Si quieres provisión delgada sin excusas delgadas,
trata la capacidad como un SLO con presupuestos, alertas y guardarraíles.

Haz lo siguiente:

1. Instrumenta lo básico: CAP del pool, FRAG, uso de snapshots, deriva de compressratio y alertas de tasa de crecimiento.
2. Escribe una política de overcommit: define máximo de sobreasignación y qué dispara “dejar de crear nuevos volúmenes thin”.
3. Protege zvols críticos: añade refreservation donde la falla de escritura sea inaceptable.
4. Arregla la mecánica de recuperación: verifica snapshots y comportamiento de discard; no asumas que borrar reclama.
5. Ensaya el runbook del 95%: sabe exactamente cómo reclamar o expandir antes de que lo necesites.

La provisión delgada puede ser una ventaja competitiva: mejor utilización, aprovisionamiento más rápido, menos compras de emergencia.
Pero solo si eres honesto sobre la factura que llega. ZFS cobrará, a tiempo, cada vez.