ZFS zpool get feature@*: Leer las capacidades reales de tu pool

Llega un momento en la vida de todo administrador ZFS en que se da cuenta de que el pool no es solo “ZFS”. Es un conjunto específico de capacidades en disco, negociadas entre el código que estás ejecutando y el historial de upgrades que permitiste. Y la forma más honesta de ver esa realidad es un comando que parece una errata hasta que te salva el fin de semana: zpool get feature@*.

Esto no es un inventario cosmético. Las banderas de características determinan qué metadatos se escriben, qué operaciones son posibles y—crucialmente—qué otros sistemas pueden importar o replicar el pool. Si alguna vez te preguntaste “¿por qué este pool no se importa en el host más antiguo?” o “¿por qué la replicación falló después de un upgrade?” ya conoces las banderas de características. Simplemente no te las habían presentado correctamente.

Qué es realmente feature@* (y por qué importa)

Las banderas de características de ZFS son marcadores en disco de capacidades específicas. Reemplazaron el antiguo esquema monolítico de “versión de pool”, donde un solo entero intentaba representar toda una historia de compatibilidad. Las banderas son más granulares: un pool puede soportar una característica moderna pero no otra. Más importante aún, una característica puede estar:

• deshabilitada (no disponible y no en uso)
• habilitada (disponible para usar; el pool la conoce)
• activa (realmente en uso en disco; has cruzado la línea de compatibilidad)

La sutileza de nivel operador es esta: “habilitada” suele significar que todavía puedes retroceder (en términos prácticos: aún no has escrito metadatos incompatibles), mientras que “activa” significa que probablemente no puedas—al menos no sin destruir y recrear el pool o hacer migraciones complejas. Por eso un pool puede importarse en una máquina antigua hasta que un día no: no “upgradearon el pool”, sino que activaron una característica al usar algo que la requería.

Otros dos términos que verás en las propiedades de las banderas:

• local: establecido directamente en este pool (a menudo vía zpool upgrade o comportamiento automático)
• received: establecido porque recibiste un pool replicado o ciertos metadatos vía send/receive (menos común a nivel de pool que a nivel de dataset, pero puede aparecer según la herramienta y la plataforma)

Broma #1 (corta, pertinente): Las banderas de características de ZFS son como un documento de políticas corporativas: nadie las lee hasta que son la razón por la que no puedes “simplemente revertir”.

Hechos e historia: cómo llegamos aquí

A la gente de almacenamiento le encanta fingir que somos atemporales, pero ZFS tiene una genealogía muy específica. Aquí hay hechos concretos y puntos de contexto histórico que cambian cómo interpretas feature@* en el mundo real:

1. Las versiones de pool fueron un callejón sin salida. ZFS temprano rastreaba un único número de “versión” para el pool. Los proveedores divergieron; la compatibilidad se volvió tan política como técnica.
2. Las banderas hicieron la compatibilidad componible. En lugar de “versión 28”, obtienes una lista: mejoras de spacemap, clases de asignación, soporte de cifrado, y más.
3. OpenZFS unificó un ecosistema fragmentado. Diferentes sistemas operativos distribuían distintas implementaciones de ZFS; las banderas fueron un mecanismo de supervivencia para la portabilidad.
4. “Habilitado” vs “activo” es oro operativo. Te permite planificar un upgrade sin comprometer inmediatamente cambios de formato en disco.
5. Algunas características son puertas de sentido único. Una vez “activa”, normalmente no puedes revertir sin reconstruir. No es una rareza de ZFS; es el coste de evolucionar formatos de metadatos de forma segura.
6. Las banderas afectan la replicación. zfs send streams pueden requerir que el destino soporte las características representadas en el stream. Esto se hace visible al mezclar versiones de SO o proveedores de appliances.
7. Los pools de arranque son especiales. En algunas plataformas, el soporte del bootloader va por detrás de las características del sistema de archivos. Un boot pool puede volverse inarrancable aunque el SO lo importe sin problemas.
8. El cifrado no es “solo una propiedad de dataset”. El cifrado nativo de ZFS depende del soporte de características; los pools creados en stacks antiguos no ganarán cifrado sin que las banderas estén presentes.
9. Los bloques grandes cambiaron la economía de cargas secuenciales. La capacidad de usar tamaños de registro más grandes (y características de bloque grande subyacentes) puede reducir la sobrecarga de metadatos y mejorar el rendimiento—hasta que choque con IO aleatorio pequeño.

Cómo leer zpool get feature@* output como un operador

Desmitifiquemos la salida. En un sistema OpenZFS verás propiedades como:

cr0x@server:~$ sudo zpool get -H -o name,property,value,source feature@* tank
tank	feature@async_destroy	enabled	local
tank	feature@empty_bpobj	active	local
tank	feature@lz4_compress	active	local
tank	feature@spacemap_histogram	active	local
tank	feature@enabled_txg	enabled	local
tank	feature@extensible_dataset	enabled	local
tank	feature@bookmarks	enabled	local
tank	feature@filesystem_limits	enabled	local
tank	feature@device_removal	disabled	-
tank	feature@allocation_classes	enabled	local
tank	feature@embedded_data	active	local
tank	feature@hole_birth	active	local
tank	feature@large_blocks	active	local
tank	feature@sha512	enabled	local
tank	feature@skein	enabled	local
tank	feature@encryption	enabled	local

Tres columnas importan en el día a día:

• property: el nombre de la característica, como feature@large_blocks
• value: disabled, enabled, o active
• source: de dónde vino esa configuración (local, -, etc.)

La interpretación operativa es:

• disabled: esta característica no está disponible en este pool. O bien tu implementación de ZFS no la conoce, o el pool no se ha actualizado para anunciarla.
• enabled: el pool anuncia la característica y puede activarla si es necesario. Aún puedes ser compatible con sistemas antiguos si nada la ha hecho “active”.
• active: algo la ha usado y escribió nuevos metadatos. Tu “superficie de importación” se ha reducido: sistemas sin esa característica no importarán.

Hay una distinción sutil pero crítica: zpool upgrade puede mover muchas características a “enabled” sin hacerlas “active”. Pero tan pronto como realizas ciertas operaciones—activar tipos de compresión, usar bookmarks, crear datasets cifrados, habilitar device removal, etc.—puedes pasar a “active”. El “cambio” no es dramático; es una escritura de metadatos. ZFS no hace drama. Hace formatos de metadatos irrevocables con checksums excelentes.

Broma #2 (corta, pertinente): La forma más rápida de aprender sobre banderas es ignorarlas una vez: nada enseña tanto como un pool que se niega a importarse a las 2 a. m.

Tareas prácticas (comandos + interpretación)

A continuación hay tareas de operador que realmente he usado en entornos tipo producción. Cada una incluye comandos y lo que deberías concluir de ellos.

Task 1: Volcar todas las banderas de un pool (la línea base)

cr0x@server:~$ sudo zpool get feature@* tank
NAME  PROPERTY                     VALUE     SOURCE
tank  feature@async_destroy         enabled   local
tank  feature@empty_bpobj           active    local
tank  feature@lz4_compress          active    local
tank  feature@spacemap_histogram    active    local
tank  feature@enabled_txg           enabled   local
tank  feature@extensible_dataset    enabled   local
tank  feature@bookmarks             enabled   local
tank  feature@filesystem_limits     enabled   local
tank  feature@device_removal        disabled  -
tank  feature@allocation_classes    enabled   local
tank  feature@embedded_data         active    local
tank  feature@hole_birth            active    local
tank  feature@large_blocks          active    local
tank  feature@sha512                enabled   local
tank  feature@skein                 enabled   local
tank  feature@encryption            enabled   local

Interpretación: Este pool ya está más allá de la “compatibilidad legacy” porque varias características están active. Si esperabas importar este pool en un host más antiguo (o en un appliance de otro proveedor), debes verificar que ese host soporte el conjunto de features active, no solo el conjunto enabled.

Task 2: Mostrar solo las características “active” (la línea de compatibilidad que cruzaste)

cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print}'
feature@empty_bpobj	active
feature@lz4_compress	active
feature@spacemap_histogram	active
feature@embedded_data	active
feature@hole_birth	active
feature@large_blocks	active

Interpretación: Esta lista es tu conjunto “debe soportar” para cualquier sistema que necesite importar el pool. Si un host de DR no puede importar, comienza comparando sus features soportadas con esta lista de activos.

Task 3: Mostrar solo las “enabled pero no active” (lo que podría ser tu próximo problema)

cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="enabled"{print}'
feature@async_destroy	enabled
feature@enabled_txg	enabled
feature@extensible_dataset	enabled
feature@bookmarks	enabled
feature@filesystem_limits	enabled
feature@allocation_classes	enabled
feature@sha512	enabled
feature@skein	enabled
feature@encryption	enabled

Interpretación: Estas son capacidades “armadas”. No necesariamente las estás usando aún, pero una acción administrativa futura (o un futuro valor por defecto) podría activarlas. Si mantienes objetivos de compatibilidad estrictos (por ejemplo, un receptor de replicación más antiguo), querrás controles de política sobre qué características pueden activarse.

Task 4: Capturar una “instantánea de capacidades del pool” para revisión de cambios

cr0x@server:~$ sudo zpool get -H -o property,value,source feature@* tank | sort > /var/tmp/tank.features.$(date +%F).txt
cr0x@server:~$ tail -n 5 /var/tmp/tank.features.$(date +%F).txt
feature@spacemap_histogram	active	local
feature@userobj_accounting	disabled	-
feature@zilsaxattr	disabled	-
feature@zpool_checkpoint	disabled	-
feature@zstd_compress	disabled	-

Interpretación: Trata el estado de las banderas como migraciones de esquema en una base de datos. Guárdalo antes de upgrades, antes de mover plataformas y antes de habilitar nuevas capacidades como cifrado o vdevs especiales.

Task 5: Verificar versión del pool/información del sistema de características juntos (reducir conjeturas)

cr0x@server:~$ sudo zpool status -x
all pools are healthy
cr0x@server:~$ modinfo zfs 2>/dev/null | head -n 5
filename:       /lib/modules/6.8.0/kernel/zfs/zfs.ko
version:        2.2.4-1
license:        CDDL
description:    ZFS
author:         OpenZFS

Interpretación: Saber “qué ZFS eres” importa al comparar soporte de características entre hosts. Mismo pool, distintos módulos ZFS, distintas características soportadas. Evita pensar “es Linux así que está bien”: la disponibilidad de features en OpenZFS depende de la versión distribuida.

Task 6: Ver qué haría zpool upgrade antes de hacerlo

cr0x@server:~$ sudo zpool upgrade
This system supports ZFS pool feature flags.

All pools are formatted using feature flags.

Some supported features are not enabled on the following pools.
Note that the pool may be upgraded to use these features, but doing so
may prevent the pool from being imported on other systems that do not
support the features.

POOL  FEATURE
tank  project_quota
tank  spacemap_v2

Interpretación: Este es tu “diff”. Te dice las características que tu software actual soporta y que tu pool todavía no habilitó. Si tu sitio de DR o el objetivo de replicación está desfasado, esta salida es una etiqueta de advertencia, no una sugerencia.

Task 7: Actualizar un pool deliberadamente (y entender el radio de impacto)

cr0x@server:~$ sudo zpool upgrade tank
This system supports ZFS pool feature flags.

Enabled the following features on 'tank':
  project_quota
  spacemap_v2

Interpretación: Esto típicamente marca las características como enabled, no necesariamente active. Pero ahora has hecho posible que operaciones futuras las activen—y podrías haber reducido la compatibilidad con sistemas que ni siquiera reconocen las features habilitadas, dependiendo de la implementación. La suposición segura: después de habilitar nuevas características, prueba la importación en cualquier sistema que deba poder importar.

Task 8: Encontrar fallos de import relacionados con features (lee el error, no improvises)

cr0x@drhost:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
status: The pool uses the following feature(s) not supported on this system:
        spacemap_histogram
        embedded_data
action: Upgrade the system to support the pool features, or recreate the pool from backup.
   see: zpool-features(7)
config:

        tank        UNAVAIL  unsupported feature(s)
          raidz2-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
            sdc     ONLINE
            sdd     ONLINE

Interpretación: Esta salida te entrega la lista de culpables. Contrástala con las “active features” en el origen. Si el host de DR no puede actualizarse, tus opciones son: mantener un pool de compatibilidad para replicación, usar copias a nivel de archivo o reconstruir un pool sin esas características (normalmente requiriendo migración de datos).

Task 9: Mapear las banderas del pool al comportamiento de datasets que te importan (ejemplo cifrado)

cr0x@server:~$ sudo zpool get -H -o value feature@encryption tank
enabled
cr0x@server:~$ sudo zfs create -o encryption=on -o keyformat=passphrase tank/secret
Enter new passphrase:
Re-enter new passphrase:
cr0x@server:~$ sudo zfs get -H -o property,value encryption,keystatus tank/secret
encryption	on
keystatus	available

Interpretación: El soporte de la característica a nivel de pool es un prerrequisito. El pool puede anunciar feature@encryption como enabled, pero se vuelve operacionalmente relevante cuando realmente creas datasets cifrados. Eso también puede afectar flujos de replicación y manejo de claves en arranque.

Task 10: Verificar alineación de features de compresión (zstd vs lz4)

cr0x@server:~$ sudo zpool get -H -o value feature@lz4_compress tank
active
cr0x@server:~$ sudo zpool get -H -o value feature@zstd_compress tank
disabled
cr0x@server:~$ sudo zfs set compression=lz4 tank/data
cr0x@server:~$ sudo zfs get -H -o value compression tank/data
lz4

Interpretación: Si replicarás a un objetivo que no soporta zstd, usar zstd en el origen puede convertirse en una trampa de migración. Las banderas pueden advertirte antes de que empieces a “optimizar” con el códec más nuevo.

Task 11: Detectar si los bloques grandes están en juego (y por qué cambia el tuning)

cr0x@server:~$ sudo zpool get -H -o value feature@large_blocks tank
active
cr0x@server:~$ sudo zfs get -H -o property,value recordsize tank/data
recordsize	128K
cr0x@server:~$ sudo zfs set recordsize=1M tank/data
cr0x@server:~$ sudo zfs get -H -o value recordsize tank/data
1M

Interpretación: Los bloques grandes pueden ser una gran ganancia para IO secuencial (backups, media, analítica), pero no son gratis. Una vez que empiezas a aumentar recordsize, las cargas de trabajo de sobrescritura aleatoria pueden castigarte con amplificación read-modify-write. Las banderas te dicen si el pool puede soportar el metadato requerido para bloques grandes de forma segura.

Task 12: Confirmar qué cambió tras una operación riesgosa (diff antes/después)

cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | sort > /var/tmp/features.before
cr0x@server:~$ sudo zfs set compression=zstd tank/data
cannot set property for 'tank/data': 'compression' feature is not enabled
cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | sort > /var/tmp/features.after
cr0x@server:~$ diff -u /var/tmp/features.before /var/tmp/features.after

Interpretación: ZFS rechazó el cambio porque el pool no anuncia la feature de compresión zstd. Este es el camino feliz: aprendiste sin activar nada. Haz este tipo de “test de fallo intencional” dentro de una ventana de cambios cuando estés considerando nuevas features.

Task 13: Vincular banderas a contabilidad de espacio y comportamiento del alocador (spacemap histogram)

cr0x@server:~$ sudo zpool get -H -o value feature@spacemap_histogram tank
active
cr0x@server:~$ sudo zdb -bbbbb tank 2>/dev/null | head -n 20

Interpretación: Cuando estás en discusiones profundas sobre rendimiento del alocador o fragmentación, las features relacionadas con spacemap importan. Si comparas dos pools y uno tiene features de spacemap más nuevas activas, su comportamiento bajo churn puede diferir lo suficiente como para invalidar benchmarks ingenuos.

Task 14: Verificar que el receptor de replicación no falle (chequeo práctico de compatibilidad)

cr0x@source:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort > /var/tmp/source.active
cr0x@receiver:~$ sudo zpool get -H -o property,value feature@* backup | awk '$2!="disabled"{print $1}' | sort > /var/tmp/recv.known
cr0x@receiver:~$ comm -23 /var/tmp/source.active /var/tmp/recv.known
feature@embedded_data
feature@spacemap_histogram

Interpretación: Esto no es un oráculo perfecto de compatibilidad (los streams de dataset y el soporte de propiedades también importan), pero es una advertencia temprana fuerte. Si el receptor ni siquiera reconoce una feature activa en el origen, espera problemas de importación y posiblemente de send/receive.

Tres microhistorias del mundo corporativo

Mini-historia 1: Un incidente causado por una suposición errónea

El escenario era el clásico “madurez híbrida” corporativa. Producción corría en Linux más reciente con un módulo OpenZFS moderno. DR corría en un appliance soportado por el proveedor que no se había actualizado porque “el almacenamiento es estable” y nadie quería reabrir la conversación de compras. La replicación era a nivel de archivo para algunos datasets y por ZFS send/receive para otros, y en general funcionaba—hasta que un día no.

Una falla de hardware rutinaria en producción escaló a un problema de instalación. El runbook de DR decía: “Importa el pool replicado en DR y levanta los servicios”. El de guardia hizo exactamente eso, y la importación del pool falló con “unsupported feature(s)”. La reacción humana inmediata fue predecible: desconfiar de la caja de DR, asumir un problema de cable, reseatear discos, intentar de nuevo, cambiar controladoras, intentar otra vez. El tiempo desapareció en el vacío donde muere la esperanza.

La causa raíz fue aburrida: en algún momento, producción había habilitado features más nuevas durante una ventana de mantenimiento—nada dramático, solo “mantener al día”. Esas features quedaron habilitadas silenciosamente, y más tarde se volvieron activas cuando alguien usó una capacidad que dependía de ellas (el tipo de acción que se siente como un ajuste de dataset, no como un evento de compatibilidad de pool). DR nunca se actualizó, y nadie comparó las banderas entre entornos.

La solución no fue un truco ingenioso. Actualizaron la plataforma de DR (tras un proceso de excepción que tomó menos tiempo que el troubleshooting fallido), re-importaron y recuperaron. La acción del postmortem que realmente se mantuvo fue simple: las instantáneas de banderas de características pasaron a ser parte de cada revisión de preparación de DR. No como ejercicio de hoja de cálculo—salida real de comandos almacenada con registros de cambio.

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

Otra organización tuvo un problema de rendimiento: jobs analíticos nocturnos tardaban mucho y la presión era “hacer ZFS más rápido”. Alguien sugirió registros más grandes y compresión más nueva. Ideas razonables, y en laboratorio se veían bien: mayor throughput, menos IO por gigabyte. El equipo programó el cambio y lo desplegó con confianza.

Luego llegaron los tickets de soporte. Servicios sensibles a la latencia que compartían el pool empezaron a incumplir SLOs. Los jobs analíticos estaban más felices, pero la carga mixta se convirtió en un conflicto: escrituras aleatorias y reescrituras empezaron a pagar el precio de la amplificación read-modify-write, y el comportamiento de la caché se volvió extraño. Encima, habían cambiado a una zona de features más nuevas, lo que hizo su plan de “rollback por si acaso” una fantasía. Podían revertir propiedades; no podían revertir el tiempo.

La falla técnica no fue “los bloques grandes son malos”. Fue asumir que el pool era una única carga de trabajo. Las banderas de características fueron parte de la historia porque hicieron la optimización durable: una vez que el pool y los datasets vivían en el nuevo mundo de metadatos, mover los datos de vuelta a sistemas más antiguos—o simplemente levantar un entorno paralelo con compatibilidad antigua—se volvió un proyecto.

La resolución eventual fue más arquitectónica que heroica: separar cargas en pools distintos (o al menos en clases de vdev separadas cuando procede), usar registros grandes donde el patrón de acceso fuera verdaderamente secuencial y mantener valores conservadores por defecto para datasets de propósito general. La lección que el equipo dejó escrita en texto claro fue: “Cada control de rendimiento también es un control de compatibilidad, aunque no lo parezca”.

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

Esta no hizo a nadie famoso, exactamente por eso funcionó. Un equipo de plataforma tenía una regla: antes de cualquier upgrade relacionado con ZFS—kernel, paquete OpenZFS o upgrade de pool—capturaban un “bundle de estado de almacenamiento” estándar. Incluía zpool status, zpool get feature@*, propiedades clave de datasets y una prueba rápida de replicación a un receptor de staging. Sin excepciones, no “lo haremos después”.

Durante una renovación de infraestructura, tuvieron que mover un pool a hardware nuevo con rapidez. El plan era exportar, mover discos e importar. Sencillo. El equipo ejecutó su bundle de estado y notó un detalle incómodo: un puñado de features estaban habilitadas pero no activas, y uno de los consumidores downstream era un sistema más antiguo usado para un archivo de cumplimiento. Ese sistema no tenía camino de upgrade en el calendario.

Porque lo detectaron temprano, tomaron una decisión deliberada: no activar nuevas características durante la ventana de migración, mantener estable la ruta de replicación al archivo y programar una actualización a más largo plazo del sistema de archivo. También verificaron que el entorno de arranque objetivo pudiera manejar el conjunto de features del pool, evitando un pie en falso con el boot-pool.

La migración ocurrió, nada se rompió y nadie fuera del equipo lo notó—que es el mayor elogio en operaciones. En el retrospectivo, el “movimiento heroico” fue literalmente un archivo de texto que contenía la salida de zpool get feature@*, capturada en el momento adecuado.

Guía de diagnóstico rápido

Cuando algo huele raro—fallos de importación, errores de replicación, regresiones de rendimiento—las banderas de características no siempre son la causa, pero a menudo son la forma más rápida de dejar de adivinar. Aquí tienes una guía pragmática que te lleva a “¿es esto un problema de compatibilidad de features?” rápidamente y luego pivota a buscar cuellos de botella.

Paso 1: Determinar si tratas con compatibilidad o rendimiento

Si el problema es “no se puede importar”, es casi seguro compatibilidad. Si el problema es “lento”, las banderas pueden contribuir indirectamente (comportamiento del alocador, tamaños de bloque, etc.), pero aún necesitas identificar el cuello de botella.

cr0x@server:~$ sudo zpool import
cr0x@server:~$ sudo zpool status -x
cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2!="disabled"{print}' | head

Interpretación: Los errores de importación listan explícitamente las features no soportadas. Si la importación funciona, pasa a las comprobaciones de rendimiento.

Paso 2: Para problemas de importación/replicación, compara las features “active” con el otro host

cr0x@source:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort
cr0x@target:~$ sudo zpool get -H -o property,value feature@* backup | awk '$2!="disabled"{print $1}' | sort

Interpretación: Cualquier feature activa en el origen y desconocida/deshabilitada en el destino es una bandera roja. No investigues cables cuando tus metadatos están hablando claro.

Paso 3: Para rendimiento, revisa los cuellos de botella clásicos de ZFS en orden

1. Salud del pool y errores de vdev (un pool degradado puede “funcionar” pero ser lento)
2. Saturación de IO (un vdev saturado mientras otros están inactivos)
3. Presión del ARC (misses de caché que provocan churn en disco)
4. Comportamiento de escrituras sync (SLOG o ausencia; la app hace fsyncs en ráfaga)
5. Desajuste recordsize/compresión (la carga no está alineada)

cr0x@server:~$ sudo zpool status -v tank
cr0x@server:~$ sudo zpool iostat -v tank 1 10
cr0x@server:~$ sudo arcstat 1 10
cr0x@server:~$ sudo zpool get -H -o property,value ashift,autotrim,feature@* tank | head -n 20
cr0x@server:~$ sudo zfs get -r -H -o name,property,value recordsize,compression,atime,sync tank/data | head -n 20

Interpretación: Las banderas no te dirán “este vdev está saturado”, pero sí te indicarán si estás en un mundo donde ciertas optimizaciones son posibles o ya están activas. Combina ambos: capacidades y comportamiento actual.

Errores comunes: síntomas y soluciones

Mistake 1: Tratar “enabled” como “seguro” sin entender la activación

Síntoma: “Actualizamos el pool hace semanas y todo iba bien; ahora la importación en DR falla.”

Por qué pasa: Habilitaste features y luego realizaste una acción que activó una. La rotura aparece con retraso.

Solución: Rastrear las features active a lo largo del tiempo. Implementar una política: si el objetivo de DR está desfasado, limitar operaciones que puedan activar features incompatibles hasta que los destinos se actualicen.

Mistake 2: Upgradear un boot pool como si fuera un pool de datos

Síntoma: El sistema importa el pool bien desde un entorno de rescate, pero no arranca normalmente.

Por qué pasa: El soporte del bootloader no es idéntico al soporte de ZFS en tiempo de ejecución en algunas plataformas.

Solución: Validar las restricciones del bootloader antes de habilitar nuevas features en boot pools. Mantén los boot pools conservadores; actualízalos solo con confirmación explícita de la plataforma y un plan de rollback.

Mistake 3: Asumir que send/receive “simplemente funcionará” entre versiones mezcladas

Síntoma: La replicación falla con errores sobre features no soportadas, bookmarks o incompatibilidad de stream.

Por qué pasa: El origen crea streams que requieren features no soportadas en el receptor (a nivel de pool y dataset).

Solución: Estandariza las versiones receptoras o usa un host de staging de compatibilidad que reciba del origen y luego reenvíe en un formato restringido (cuando sea posible). Más a menudo, la solución es “actualizar el receptor”.

Mistake 4: Habilitar features brillantes durante un incidente

Síntoma: Un intento de recuperación empeora la situación: el nuevo pool no se puede importar en otro lado, la cadena de replicación se rompe o desaparecen opciones de rollback.

Por qué pasa: Bajo presión, alguien ejecuta zpool upgrade -a o cambia propiedades para “mejorar el rendimiento”, activando features sin querer.

Solución: En modo incidente, congelar el estado de features. Hacer de “no actualizar pools durante incidentes” una regla permanente a menos que el upgrade sea la solución explícita con un plan de compatibilidad confirmado.

Mistake 5: Usar banderas de características como proxy de tuning de rendimiento

Síntoma: “Habilitamos todo y sigue lento”, o el rendimiento empeora después de “upgradear”.

Por qué pasa: Las features son capacidades, no multiplicadores de throughput. El rendimiento depende del layout de vdev, la carga, ARC, comportamiento sync, fragmentación y más.

Solución: Usa la guía de diagnóstico rápido: prueba el cuello de botella con iostat/latencia/estadísticas ARC primero, luego decide si las features y propiedades son relevantes.

Listas de verificación / plan paso a paso

Checklist: Antes de ejecutar zpool upgrade en producción

1. Captura el estado actual de features.
2. Identifica todos los sistemas que deben importar o recibir desde este pool.
3. Confirma sus versiones ZFS/OpenZFS y las features soportadas.
4. Ejecuta zpool upgrade (sin args) para ver qué cambiaría.
5. Decide: actualizar ahora, luego o selectivamente (pool por pool).
6. Prepara y prueba la importación/receive en un host no productivo si puedes.

cr0x@server:~$ sudo zpool get -H -o property,value,source feature@* tank | sort > /var/tmp/tank.features.pre
cr0x@server:~$ sudo zpool upgrade
cr0x@server:~$ sudo zpool upgrade tank
cr0x@server:~$ sudo zpool get -H -o property,value,source feature@* tank | sort > /var/tmp/tank.features.post
cr0x@server:~$ diff -u /var/tmp/tank.features.pre /var/tmp/tank.features.post | head -n 50

Checklist: Cuando planificas una migración de plataforma

1. En el origen: lista las features activas.
2. En el destino: confirma que reconoce/soporta esas features.
3. Confirma restricciones de boot pool si el pool es crítico para arranque.
4. Exporta/importa en una ventana controlada; verifica con un schedule de scrub.

cr0x@source:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort > /var/tmp/tank.active
cr0x@target:~$ sudo zpool get -H -o property,value feature@* tank 2>/dev/null | awk '$2!="disabled"{print $1}' | sort > /var/tmp/target.known
cr0x@target:~$ comm -23 /var/tmp/tank.active /var/tmp/target.known

Checklist: Construir un “contrato de compatibilidad” para DR

1. Define el sistema más antiguo que debe importar pools.
2. Congela la activación de características del pool más allá de lo que ese sistema soporta.
3. Programa upgrades de DR junto con producción, no “más tarde”.
4. Audita trimestralmente: compara features activas y ejecuta una importación/receive de prueba.

cr0x@prod:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort > /var/tmp/prod.active
cr0x@dr:~$ sudo zpool import 2>&1 | sed -n '1,30p'

Preguntas frecuentes

1) ¿Qué muestra realmente zpool get feature@*?

Muestra las propiedades de banderas de características del pool: qué features en disco están deshabilitadas, habilitadas o activas. Es la vista más directa de lo que el pool puede hacer y de qué formatos de metadatos puede estar usando ya.

2) ¿Cuál es la diferencia entre “enabled” y “active”?

Enabled significa que el pool anuncia la característica y puede usarla. Active significa que la característica está en uso en disco—se han escrito metadatos que la requieren. Active es la línea que típicamente rompe la compatibilidad de importación con sistemas más antiguos.

3) ¿Ejecutar zpool upgrade hace que las features sean inmediatamente activas?

Normalmente las habilita, pero la activación ocurre típicamente cuando realizas operaciones que requieren esas features. El riesgo operativo es diferido: puedes habilitar hoy y romper la importación en DR el próximo mes cuando una feature se vuelva activa.

4) ¿Puedo “downgradear” un pool o desactivar una feature activa?

No en el caso general. Una vez activa, el estado en disco del pool depende de ella. La vía práctica de downgrade es migrar los datos a un pool nuevo creado con las restricciones de compatibilidad deseadas.

5) ¿Por qué un pool falla al importarse en otro sistema?

Porque la implementación de ZFS en ese sistema no soporta una o más features que están activas en el pool. El error de importación típicamente lista los nombres exactos de las features.

6) ¿Las banderas de características son las mismas en todas las implementaciones de ZFS?

En el ecosistema OpenZFS están en gran medida alineadas, pero no todas las plataformas distribuyen la misma versión de OpenZFS, y algunos proveedores de appliances retrasan o restringen actualizaciones. Trata “ZFS” como un nombre de familia; el soporte de features depende de la build específica.

7) ¿Las banderas me dicen por qué el rendimiento es lento?

No directamente. Te indican qué capacidades existen (o están en uso) que podrían influir en características de rendimiento—como comportamiento de spacemap o soporte de bloques grandes. Para cuellos de botella reales, usa zpool iostat, estadísticas ARC y métricas específicas de la carga.

8) ¿Cómo se relacionan las banderas con propiedades de dataset como compresión o cifrado?

Algunas propiedades de dataset requieren soporte a nivel de pool. Si el pool no tiene la feature relevante habilitada, ZFS rechazará establecer la propiedad (mejor caso) o activarás una feature cuando empieces a usar la capacidad (caso común).

9) Si una feature está “enabled” pero no “active”, ¿debería preocuparme?

Al menos deberías estar al tanto. Las features habilitadas son una capacidad que podrías activar accidentalmente mediante operaciones normales. Si tienes requisitos de interoperabilidad estrictos, enabled-pero-no-active es un ítem de gestión de cambios.

10) ¿Qué es lo más útil que debo almacenar para futuras investigaciones?

Una instantánea fechada de la salida de zpool get feature@* (más zpool status) tomada antes y después de upgrades. Es evidencia de bajo esfuerzo que evita conjeturas de alto esfuerzo más adelante.

Conclusión

zpool get feature@* es lo más parecido a un suero de la verdad que tiene ZFS. Te dice de qué es capaz tu pool, a qué se ha comprometido ya en disco y dónde están dibujadas las líneas de compatibilidad—ya sea que las trazaste a propósito o no. En producción, eso no es trivia; es la diferencia entre un upgrade controlado y un proyecto de migración sorpresa.

Si debes adoptar solo un hábito operativo de esto: controla las features active como controlas las versiones de esquema. Guarda la salida, haz diff durante cambios y hazla parte de la preparación de DR. ZFS hará felizmente lo correcto durante años—hasta que pidas a un sistema antiguo que entienda un futuro que nunca aprendió.