zfs get es de esos comandos que parecen aburridos hasta que te ahorran tocar algo que no deberías tocar. En Proxmox lo uso antes de cambiar propiedades de un dataset, antes de asumir que una VM está mal configurada y antes de meter mano a ZFS con esa alegría peligrosa que aparece cuando llevas demasiadas horas delante de una terminal.
ZFS tiene muchas propiedades. Algunas se heredan. Algunas se fijan localmente. Algunas cambian rendimiento. Algunas cambian comportamiento. Algunas parecen inocentes y luego te dejan una tarde muy entretenida. Por eso me gusta mirar antes de actuar.
El comando más básico es este.
| |
Pero casi nunca necesito todo. all escupe demasiada información para una revisión rápida. Yo suelo empezar por propiedades concretas.
| |
Y si estoy mirando un disco de VM o un dataset concreto, apunto directamente a ese recurso.
| |
No cambia nada. Solo lee. Eso ya lo convierte en un buen comando para usar cuando no estás seguro.
la captura de este post#
La captura usa una salida saneada de un entorno Proxmox con ZFS. Los nombres son genéricos. No hay rutas privadas, hostnames reales ni datos que identifiquen el laboratorio. Me interesa enseñar cómo leo columnas y valores, no el inventario de nadie.
Esta es la salida saneada que usé para generar la captura:
| |
Esta salida ya dice varias cosas. El dataset de plantillas tiene compression=zstd y atime=off fijados localmente. recordsize y sync vienen por defecto. El disco de VM hereda compresión del pool, tiene volblocksize=16K y mantiene sync=standard.
No hay que tocar nada para aprender bastante.
por qué miro SOURCE y no solo VALUE#
La columna que más gente ignora es SOURCE. Error clásico.
VALUE te dice el valor actual. SOURCE te dice de dónde viene. Puede ser local, default, inherited o algo más específico según la propiedad. Esa diferencia importa mucho en ZFS.
Si veo esto:
| |
sé que ese dataset no tiene una decisión propia. Está siguiendo lo que marca el padre. Si cambio el padre, puede cambiar el comportamiento de varios hijos. Eso exige más cuidado.
Si veo esto:
| |
sé que alguien fijó ese valor en ese dataset. Aunque cambie el padre, ese dataset seguirá con su valor local hasta que lo herede de nuevo o lo cambie expresamente.
Esa es una diferencia enorme cuando estás limpiando configuración. Si solo miras VALUE, puedes pensar que todos los datasets están igual. Si miras SOURCE, ves cuáles están igual por herencia y cuáles están igual porque alguien los dejó clavados.
En un homelab pequeño quizá no parece importante. En cuanto tienes varias VMs, backups, plantillas y datasets para servicios, empieza a importar bastante.
propiedades que reviso casi siempre#
No miro todas las propiedades de ZFS cada vez. Sería absurdo. Tengo un grupo pequeño que me da contexto rápido.
compression es la primera. En la mayoría de mis datasets prefiero tener compresión activa. ZFS suele ganar más de lo que pierde, especialmente con lz4 o zstd en niveles razonables. Pero quiero saber si está activada, si se hereda y si alguien la cambió solo en un dataset.
atime también la miro mucho. En datasets con muchos archivos pequeños, tener atime=on puede generar escrituras extra cada vez que se accede a un archivo. No siempre es grave, pero en plantillas, backups o datos que no necesitan registrar último acceso, suelo preferir off.
recordsize me interesa en datasets de archivos. No lo trato como una palanca mágica. Para datos generales, 128K suele estar bien. Para bases de datos o cargas muy concretas, puede tener sentido otro valor. Lo importante es no tocarlo por copiar una recomendación suelta de internet.
sync la miro con respeto. standard es lo normal. always puede tener sentido en ciertos escenarios. disabled puede dar rendimiento aparente, pero también puede darte una lección cara si hay un corte o una caída. En laboratorio se puede probar. En datos importantes, cuidado.
mountpoint parece aburrida hasta que un dataset se monta donde no debe. Cuando algo aparece o desaparece de una ruta, miro esto pronto.
En discos de VM también miro volblocksize, aunque ahí hay una trampa importante: no es una propiedad que cambies alegremente después de crear el zvol. Si te equivocaste al crear el disco, normalmente toca planificar migración o recreación, no apretar botones como si fuese un toggle de interfaz.
datasets y zvols no se leen igual#
En Proxmox te vas a encontrar datasets de archivos y zvols para discos de VM. Los dos viven en ZFS, pero no conviene leerlos con la misma cabeza.
Un dataset de archivos puede tener propiedades como recordsize y mountpoint que afectan bastante a cómo se comporta. Por ejemplo, un dataset para plantillas ISO, backups temporales o datos de servicios tiene sentido mirarlo como un árbol de archivos.
Un zvol de VM funciona como un bloque. Ahí me fijo más en volblocksize, compresión y sync. También miro si hereda propiedades del pool o si tiene algo local extraño.
Esto es una salida típica para un zvol.
| |
Y esto para un dataset de archivos.
| |
La diferencia parece pequeña, pero evita conclusiones torpes. Si estás leyendo un zvol y te obsesionas con propiedades que no aplican como esperas, pierdes tiempo. Si estás leyendo un dataset y no miras mountpoint, puedes perder una pista evidente.
el caso típico: una VM que consume más de lo esperado#
Una VM empieza a ocupar más disco del que debería. La web de Proxmox enseña un tamaño. ZFS enseña otro. El sistema invitado enseña otro. Bienvenido a una tarde normal.
Antes de tocar nada, miro propiedades.
| |
Aquí no busco una verdad absoluta. Busco contexto. logicalused me da una idea del uso lógico. used enseña lo que ZFS está consumiendo con sus reglas. compressratio me dice si la compresión está ayudando algo.
Si la compresión está activa pero el ratio es bajo, no pasa nada. No todo comprime. Un disco lleno de vídeos, backups comprimidos o datos cifrados no va a hacer milagros. ZFS no es magia, aunque a veces lo vendan como si fuese una liturgia.
Si la compresión está desactivada en ese zvol y activada en otros, miro SOURCE. Quizá alguien fijó compression=off localmente hace meses. Ahí zfs get me evita una discusión con fantasmas.
el caso incómodo: sync desactivado#
Cuando encuentro esto, paro un momento.
| |
No digo que sea siempre incorrecto. En homelab hacemos pruebas. A veces buscas rendimiento para una carga temporal. A veces quieres medir diferencias. El problema es olvidarte de que lo dejaste así.
Con sync=disabled, ZFS puede responder más rápido a escrituras síncronas porque no las trata con la misma garantía. Eso puede parecer una mejora brutal en benchmarks, pero no es gratis. Si hay una caída, puedes perder datos que la aplicación creía confirmados.
Para una VM de pruebas, me da igual. Para una base de datos, un servicio importante o algo que no quiero reconstruir, no me hace gracia.
Por eso me gusta mirar sync directamente.
| |
Y si quiero buscar rarezas en todo el pool:
| |
Ese comando es casi una inspección de higiene. Si no devuelve nada, mejor. Si devuelve algo, quiero saber por qué.
usar -r sin ahogarte en salida#
-r recorre datasets hijos. Es útil, pero puede escupir demasiado.
| |
En un pool pequeño se lee bien. En uno con muchas VMs, snapshots y datasets, puede ser ruido. Por eso suelo combinarlo con propiedades concretas y filtros simples.
Para ver compresión y origen:
| |
Para buscar datasets con compresión desactivada:
| |
Para revisar atime:
| |
Para encontrar valores locales:
| |
No es sofisticado. Funciona. A veces en administración de sistemas confundimos sofisticación con utilidad y luego acabamos con un dashboard precioso para evitar leer una columna.
cuidado con cambiar propiedades por impulso#
zfs get es lectura. El peligro viene justo después, con zfs set.
Ver una propiedad rara no significa que debas cambiarla en caliente. Primero hay que entender qué recurso estás mirando, qué carga mueve, si hay snapshots, si hay backups recientes y si el cambio afecta solo a ese dataset o a hijos que heredan.
Ejemplo sencillo:
| |
Puede ser una decisión razonable. Pero si tienes muchos hijos heredando compresión, acabas de cambiar el comportamiento futuro de todos los que no tengan valor local. Quizá eso es lo que quieres. Quizá no.
Otro ejemplo:
| |
En un dataset de plantillas puede tener sentido. En otro tipo de datos quizá una aplicación sí espera atime. No es lo más común, pero existe.
Y con sync, directamente no juego sin pensar.
| |
Ese comando puede convertir una prueba de rendimiento en una ruleta. Si lo uso, lo documento y lo revierto. Si no lo documento, dentro de tres semanas yo mismo me odiaré un poco. Con razón.
cómo lo documento cuando encuentro algo raro#
Cuando zfs get me enseña una propiedad rara, guardo tres cosas.
Primero, la salida exacta.
| |
Segundo, el motivo si lo conozco. Por ejemplo: “sync desactivado para prueba de benchmark, volver a standard al terminar”.
Tercero, la fecha. Parece obvio. No lo es. En un homelab con cambios pequeños, saber cuándo tocaste algo vale oro.
También miro zpool history para ver si el cambio aparece registrado.
| |
Así conecto la propiedad actual con el momento en que se cambió. zfs get me dice cómo está. zpool history me ayuda a saber cuándo llegó ahí.
mi comando corto favorito#
Si solo quiero una lectura rápida de un dataset de archivos, suelo usar esto.
| |
Si es un disco de VM:
| |
Con eso tengo bastante para decidir si sigo investigando ZFS o si miro otra capa. No necesito veinte propiedades para cada sospecha. Necesito las que cambian la historia.
lo que me gusta de zfs get#
Me gusta porque es seguro. Leer antes de tocar debería ser norma, pero en homelab a veces nos venimos arriba. zfs get te obliga a mirar el estado real y, sobre todo, el origen del valor.
También me gusta porque explica diferencias que en la web de Proxmox no siempre se ven claras. Dos discos pueden parecer iguales y no serlo. Dos datasets pueden tener la misma compresión por motivos distintos. Un valor local olvidado puede sobrevivir durante meses y condicionar una VM sin que nadie se acuerde.
No es el comando más emocionante de ZFS. Mejor. Los comandos emocionantes en almacenamiento suelen venir acompañados de sudor.
Mi regla es simple: si voy a tocar una propiedad, antes la leo. Si una VM o dataset se comporta raro, leo sus propiedades antes de culpar al nodo. Si veo un valor local inesperado, miro historial. Y si no entiendo por qué está así, no lo cambio hasta tener una copia buena o una razón decente.
En Proxmox, esa prudencia parece aburrida. También es la diferencia entre una tarde tranquila y una noche intentando recordar por qué una VM importante dejó de arrancar después de “solo un cambio pequeño”.