zfs inherit es el comando que uso cuando quiero dejar de discutir con mi yo del pasado. Ese señor, normalmente con sueño y una confianza insultante, decidió un día que un dataset necesitaba una propiedad local distinta. Meses después aparece un comportamiento raro, miro zfs get y veo la palabra que casi siempre explica el misterio: local.
No siempre es malo. Una propiedad local puede ser justo lo que querías. El problema es cuando ya no sabes por qué está ahí. En ZFS, la herencia es una de las partes más cómodas del sistema. Pones una propiedad en un padre, los hijos la heredan y mantienes una configuración limpia. Cuando llenas el árbol de excepciones locales, empiezas a convertir tu pool en una colección de notas adhesivas pegadas a oscuras.
zfs inherit quita una propiedad local de un dataset para que vuelva a heredar el valor del padre, o para que use el valor por defecto si no hay nada que heredar. No borra datos. No destruye el dataset. Pero cambia comportamiento, así que tampoco lo trato como un juguete.
El comando base es este.
| |
Por ejemplo.
| |
Después miro siempre el resultado.
| |
La clave está en la columna SOURCE. Si cambia de local a inherited from pve-zfs, ya sé que la excepción desapareció.
la captura de este post#
La captura usa una salida saneada de un entorno Proxmox con ZFS. Los nombres son genéricos y los valores no enseñan nada privado. La idea es ver el flujo: detectar una propiedad local, quitarla y comprobar que vuelve a heredar.
Esta es la salida saneada que usé para generar la captura:
| |
Esta salida cuenta una historia bastante clara. templates tenía compression=zstd y atime=off puestos como valores locales. El padre tiene compression=lz4 local y atime=on por defecto. Al heredar, templates vuelve a lz4 por el padre y a atime=on por defecto.
No hay magia. Hay orden.
por qué me importa tanto SOURCE#
Cuando uso zfs get, no miro solo el VALUE. Miro SOURCE casi con más interés. El valor te dice qué está pasando ahora. La fuente te dice por qué está pasando.
| |
Una salida como esta me da tranquilidad.
| |
Una salida como esta me hace preguntar qué pasó.
| |
Puede que zstd sea correcto. Puede que lo pusiera porque ese dataset guarda plantillas comprimibles. O puede que fuera una prueba y se quedase ahí porque nadie limpió después. La diferencia no está en el comando. Está en la intención. Y la intención caduca rápido si no la documentas.
mi caso típico#
El caso más habitual en mi homelab es un dataset auxiliar que acaba distinto al resto. Por ejemplo, uno para plantillas, ISOs, pruebas o datos temporales. Lo ajusto un día para probar compresión, cuota o atime. Luego pasa el tiempo. Más adelante reviso el pool y encuentro una mezcla de propiedades que ya no responde a una lógica clara.
Para verlo de golpe uso recursivo.
| |
Salida saneada.
| |
Aquí ya tengo trabajo. templates tiene dos decisiones locales. lab tiene atime=off local. Igual todo eso tiene sentido. O igual es basura histórica. Lo que no hago es lanzar zfs inherit en todo como si estuviera pasando la escoba por el garaje. Primero decido qué excepciones quiero conservar.
inherit no es revertir el tiempo#
Esto conviene grabarlo. zfs inherit no vuelve al pasado. No recompone datos ya escritos. No deshace un cambio de compresión sobre bloques que ya se escribieron. No sabe si una propiedad local se puso por una buena razón.
Solo quita la propiedad local para que ZFS calcule el valor efectivo desde la herencia o desde el default.
Si tenías compression=zstd local y heredas compression=lz4, las nuevas escrituras usarán lz4. Los datos antiguos no se transforman en otra cosa por cambiar la propiedad. Para eso tendrías que reescribir datos. Lo mismo ocurre con otros ajustes que afectan a escrituras futuras.
Por eso uso inherit como limpieza de configuración, no como máquina del tiempo.
antes de heredar, miro al padre#
Nunca heredo una propiedad sin mirar qué valor voy a recibir. Parece obvio, pero es una de esas obviedades que salvan tardes.
| |
Si el padre tiene un valor raro, heredar solo mueve el problema. No lo arregla. De hecho, puede empeorar las cosas si el hijo estaba local precisamente para escapar de una mala decisión en el padre.
También miro si hay más hijos afectados por el mismo patrón.
| |
Si solo un dataset está distinto, puede ser una excepción deliberada. Si hay diez datasets con valores locales diferentes, suele ser señal de experimentos acumulados. El homelab, ese sitio donde la arqueología y la informática se dan la mano.
usar -S para ver solo propiedades locales#
Una opción que me gusta mucho es -S, que muestra propiedades recibidas de la fuente local, recibidas o heredadas según orden de fuente. Para una limpieza rápida de excepciones locales, suelo preferir filtrar con grep local porque es más fácil de leer de madrugada.
| |
No es perfecto porque all mete muchísimo ruido. Si sé qué propiedad estoy revisando, mejor ser concreto.
| |
Esto me permite ver dónde hay decisiones locales sin navegar por toda la salida. Aun así, cuidado con limpiar por limpiar. Algunas propiedades locales están ahí porque deben estar ahí. Una cuota en un dataset de descargas, por ejemplo, puede ser justo lo que evita que un servicio idiota te llene el pool.
inherit recursivo: útil y peligroso#
Existe zfs inherit -r, que aplica la herencia de forma recursiva.
| |
Lo uso poquísimo. No porque sea malo, sino porque es muy fácil borrar excepciones que sí querías. En un entorno limpio y pequeño puede tener sentido. En un Proxmox con años de pruebas, VMs, datasets auxiliares y decisiones de domingo por la noche, me parece una herramienta para usar con mucha cabeza.
Si alguna vez lo uso, antes hago inventario.
| |
Luego guardo la salida en un fichero temporal o en una nota. No por postureo. Porque si el cambio sale raro, quiero saber qué había antes.
| |
En un post público uso rutas genéricas, pero en mi máquina real intento guardar estas cosas en un sitio que luego pueda encontrar. /tmp está bien para una operación inmediata. No está bien para documentación duradera.
propiedades que suelo heredar#
Las candidatas habituales son compression, atime, recordsize, xattr, acltype, quota y refquota. No porque haya que tocarlas todas, sino porque son las que más aparecen como valores locales después de años de pruebas.
compression y atime son las más fáciles de razonar. Si el padre define la política general, tiene sentido que muchos hijos la hereden.
recordsize me da más respeto. No lo heredo sin entender qué datos guarda ese dataset. Un valor local puede ser muy razonable para ficheros grandes o para una carga concreta.
quota y refquota las trato con cuidado. Heredar una cuota puede quitar un límite que estaba evitando problemas. También puede aplicar un límite heredado que no esperabas. Miro dos veces.
| |
Si hay reservas de espacio, aún más calma. Las reservas afectan al espacio disponible del pool y pueden darte lecturas confusas si vas con prisa.
una limpieza pequeña que sí haría#
Imagina que tengo un dataset de plantillas con dos propiedades locales puestas durante una prueba.
| |
Veo esto.
| |
El padre define compression=lz4 y no tengo motivo para mantener zstd ahí. También quiero que atime vuelva a la política normal. Entonces sí hago.
| |
Compruebo.
| |
Y miro historial.
| |
Ese último paso me gusta porque deja la operación dentro de una secuencia mental. Si dentro de una semana reviso el pool, veré cuándo quité las propiedades locales.
cuándo no heredo#
No heredo una propiedad si no sé para qué estaba. Tampoco heredo durante una incidencia seria salvo que el problema sea precisamente esa propiedad local y lo tenga claro. Si una VM está lenta, no empiezo quitando propiedades a ciegas. Primero miro I/O, estado del pool, logs, snapshots y cambios recientes.
Tampoco heredo cuotas sin revisar uso real. Una cuota puede parecer una molestia hasta que recuerdas que la pusiste para que un servicio de pruebas no se comiera todo el storage. Quitarla sin pensar es una forma muy elegante de preparar el susto de la semana siguiente.
Y no heredo propiedades de discos de VM solo porque quedan feas en la salida. En Proxmox, algunos volúmenes tienen ajustes por razones concretas. La limpieza estética en storage es una trampa. El objetivo no es que todo parezca simétrico. El objetivo es que tenga sentido.
cómo lo documento#
Cuando quito una excepción local, dejo una nota corta si el dataset importa.
| |
No hace falta escribir una tesis. Solo necesito que el próximo yo no tenga que reconstruir el caso desde cero. En homelab, la documentación buena suele ser la que realmente escribirías después de cenar. Si exige demasiada disciplina, no va a sobrevivir.
mi secuencia completa#
Mi flujo habitual es este.
| |
Primero miro el árbol. Luego miro el padre. Luego miro el hijo. Después reviso historial por si la propiedad local venía de una operación reciente. Solo entonces heredo. Al final compruebo y vuelvo a mirar historial.
Podría hacerlo en menos comandos. También podría cruzar la calle sin mirar. Prefiero no convertir la administración de storage en un acto de fe.
con qué me quedo#
zfs inherit es una herramienta pequeña, pero muy útil para mantener orden en un Proxmox con ZFS. No arregla datos antiguos, no adivina intenciones y no sustituye a entender el árbol de datasets. Lo que hace es quitar excepciones locales y devolver un dataset a la política del padre.
Mi forma de usarlo es bastante simple: busco propiedades locales, decido cuáles sobran, miro qué voy a heredar, aplico el cambio y verifico. Si no entiendo por qué una propiedad está local, no la toco todavía.
ZFS te da mucha cuerda. zfs inherit sirve para recoger un poco cuando has dejado demasiada tirada por el suelo.