zfs set es uno de esos comandos que parecen pequeños hasta que recuerdas que cambia el comportamiento de un dataset en caliente. No te pregunta dos veces. No abre una ventana simpática. No te dice “igual deberías pensarlo”. Ejecutas el comando y ZFS aplica la propiedad.
Eso es justo lo que me gusta y lo que me da respeto.
En Proxmox lo uso sobre todo para ajustar datasets auxiliares, volúmenes de laboratorio y algún disco de VM cuando sé exactamente qué quiero conseguir. La palabra importante es “exactamente”. Si entro en zfs set con una idea vaga, normalmente paro y miro antes. ZFS no es frágil, pero tampoco perdona la típica tarde de “voy a probar una cosilla rápida”.
El comando base es este.
| |
Por ejemplo.
| |
La parte peligrosa no es escribirlo. La parte peligrosa es saber dónde lo estás aplicando y si esa propiedad tiene sentido para ese tipo de datos. No trato igual un dataset de ISOs, un directorio de backups, un disco de VM con base de datos o un volumen donde guardo ficheros pequeños que cambian mucho.
la captura de este post#
La captura usa una salida saneada basada en un entorno Proxmox con ZFS. Los nombres son genéricos y los valores están pensados para enseñar el flujo sin publicar inventario privado. No hay IPs, hostnames reales ni rutas internas.
Esta es la salida saneada que usé para generar la captura:
| |
Lo que me interesa aquí no es solo el valor. Me interesa la columna SOURCE. Cuando aparece local, sé que ese dataset tiene una decisión propia. Cuando aparece default o inherited, sé que viene de otro sitio. Esa diferencia parece una tontería hasta que heredas un laboratorio montado por tu yo de hace seis meses y no entiendes por qué un dataset se comporta distinto al resto.
mi regla antes de tocar nada#
Antes de ejecutar zfs set, miro tres cosas.
| |
Primero quiero saber qué dataset estoy tocando. Segundo quiero ver sus propiedades actuales. Tercero quiero confirmar que el pool no está en medio de un drama. Si el pool ya está degradado, si hay errores o si hay un scrub pesado en marcha, no me pongo a cambiar propiedades porque sí. Ya habrá tiempo para afinar cuando el storage esté tranquilo.
También suelo mirar historial si no recuerdo qué hice antes.
| |
Esto me ha ahorrado más de una teoría absurda. A veces el misterio de rendimiento no era un bug de Proxmox, ni una controladora caprichosa, ni una maldición del kernel. Era una propiedad cambiada a las dos de la mañana.
compression: el cambio que más uso#
La propiedad que más cambio es compression. En casi todos mis pools ZFS la quiero activada. En Proxmox, para muchos datasets, lz4 sigue siendo una opción muy sensata. Es rápida, consume poco y rara vez se convierte en problema.
zstd también me gusta, sobre todo en datasets donde guardo plantillas, backups pequeños, ficheros de configuración o datos que se benefician de comprimir mejor. No lo activo a lo loco en todo porque no todo lo necesita. En máquinas con CPU decente va muy bien, pero prefiero no convertir cada ajuste en una religión.
Para ver cómo está.
| |
Para cambiarlo.
| |
Algo importante: cambiar compression no recomprime mágicamente todo lo que ya existe. Afecta a las nuevas escrituras. Esto se olvida muchísimo. Si cambio la compresión de un dataset lleno, no espero ver bajar el uso de disco de golpe. Para que los datos antiguos se reescriban, tienen que volver a escribirse. En algunos casos eso pasa con el tiempo. En otros, si quieres forzarlo, ya entras en terreno de mover datos, recrear, enviar con zfs send, recibir y cosas que no haría sin café y backup.
La lectura que suelo hacer después es esta.
| |
compressratio no es una medalla. Es una pista. Si veo 1.00x en un dataset lleno de vídeos ya comprimidos, no me sorprende. Si veo 1.00x en logs o texto, igual algo no está como pensaba.
atime: pequeño ajuste, mucha tranquilidad#
atime registra cuándo se accedió por última vez a un fichero. En muchos usos modernos no me aporta demasiado y genera escrituras extra. En datasets de plantillas, ISOs, repositorios locales o ficheros que no dependen de esa marca de acceso, suelo desactivarlo.
| |
No lo vendería como el ajuste mágico que cambia la vida. No lo es. Pero reduce ruido y evita escrituras inútiles en sitios donde no las necesito. En un homelab con SSDs y NVMes tampoco me voy a poner dramático, pero si puedo quitar trabajo que no aporta nada, lo quito.
Donde tengo más cuidado es en aplicaciones raras que sí puedan depender de tiempos de acceso. No es habitual en mis servicios, pero existe. Si no lo tengo claro, lo dejo como está.
recordsize: aquí no juego si no entiendo la carga#
recordsize es una de esas propiedades que atrae ajustes de foro con olor a incienso técnico. Para datasets de ficheros grandes puede tener sentido subirlo. Para cargas con ficheros pequeños o patrones concretos, puede tener sentido bajarlo. Para discos de VM, la historia cambia porque muchos volúmenes en Proxmox no usan recordsize como lo usaría un dataset normal.
La comprobación básica.
| |
Un cambio típico en un dataset de ficheros grandes podría ser.
| |
Pero aquí soy bastante conservador. Si no tengo una razón clara, no lo toco. El valor por defecto de 128K no es perfecto para todo, pero suele ser una base razonable. Lo peor que puedes hacer es copiar un ajuste de alguien con una carga totalmente distinta y luego culpar a ZFS porque tu VM de base de datos va rara.
Y otra vez: los datos ya escritos no cambian de estructura por arte de magia. Los nuevos registros usarán el nuevo ajuste. Los antiguos seguirán como estaban hasta que se reescriban.
quota y reservation: útiles, pero con mala leche#
quota limita cuánto puede usar un dataset. reservation reserva espacio para un dataset. Las dos propiedades son útiles. Las dos pueden darte un susto si las aplicas sin mirar el pool completo.
Una cuota sencilla.
| |
Una reserva.
| |
La cuota me gusta para datasets de pruebas, descargas, cachés o servicios que tienden a crecer sin pedir permiso. La reserva la uso con mucha más prudencia porque reduce el espacio disponible para el resto. En un homelab, donde a veces el almacenamiento crece como cajón de cables, las reservas pueden dejarte sin margen de forma bastante tonta.
Antes de poner cuotas miro esto.
| |
Si un dataset ya está cerca del límite, aplicar una cuota baja puede romper una aplicación al siguiente write. No falla de forma poética. Falla como fallan las cosas en Linux: de repente y con un mensaje que parece escrito por alguien que no quería hablar contigo.
no aplico cambios en cascada sin pensarlo#
ZFS hereda propiedades. Eso es cómodo y peligroso. Si cambias una propiedad en el padre, los hijos que heredan esa propiedad cambian con él. Los hijos que tienen valor local no cambian.
Por eso miro siempre la columna SOURCE.
| |
La opción -r baja por los hijos. Es perfecta para descubrir sorpresas.
| |
Aquí cambiar el padre afectaría a backups y al disco de VM si están heredando. No afectaría a templates, porque tiene zstd local. Esa lectura me parece obligatoria antes de tocar propiedades de arriba.
cómo dejo rastro de lo que hice#
zfs set queda registrado en zpool history, y eso ayuda. Aun así, cuando toco algo delicado, dejo una nota en mi documentación o en el ticket mental de turno. No hace falta montar una ceremonia. Una línea basta.
| |
Parece exceso hasta que pasa un mes y necesitas entender por qué un dataset no hereda lo mismo que los demás. La diferencia entre un homelab divertido y un homelab que te roba noches suele ser la memoria. Documentar lo mínimo no te hace menos hacker. Te hace menos víctima de ti mismo.
cómo revierto un cambio#
Para revertir una propiedad local y volver a heredar, uso zfs inherit. No lo meto en el mismo saco que zfs set porque mentalmente lo trato como una operación distinta: estoy quitando una decisión local.
| |
Después compruebo.
| |
Si la columna SOURCE vuelve a mostrar inherited, ya sé que ese dataset vuelve a obedecer al padre. Si muestra default, está usando el valor por defecto porque no hay valor heredado distinto.
mi checklist rápido#
Cuando voy a usar zfs set, sigo este orden.
| |
No es glamour. Es aburrimiento preventivo. Y el aburrimiento preventivo en storage es maravilloso.
errores que intento no repetir#
El primero es tocar el dataset equivocado. Parece ridículo, pero con nombres largos y discos de VM parecidos no cuesta nada confundirse. Copio y pego menos de lo que parece. Prefiero escribir el nombre o usar tab completion y mirar dos veces.
El segundo es cambiar propiedades en un padre pensando solo en un hijo. Si quiero ajustar templates, ajusto templates. Si quiero cambiar todo el pool, entonces sí miro todos los hijos y decido con calma.
El tercero es esperar resultados inmediatos en datos ya escritos. Compresión, recordsize y otras propiedades afectan a nuevas escrituras. Si no entiendes eso, puedes acabar haciendo cambios correctos y pensando que no funcionan.
El cuarto es tocar durante una incidencia. Si una VM está caída porque el pool tiene errores, lo último que necesito es añadir variables. Primero estabilizo. Luego afino.
cuándo no uso zfs set#
No lo uso para experimentar en datasets importantes. No lo uso si no tengo backup. No lo uso si estoy cansado y el cambio puede esperar. Y no lo uso porque un hilo perdido diga que tal propiedad mejora el rendimiento un 40 por ciento sin explicar la carga.
Hay ajustes que merecen una VM de pruebas o un dataset temporal.
| |
Probar en pequeño es barato. Arreglar un pool lleno de decisiones improvisadas es bastante menos divertido.
con qué me quedo#
zfs set es una herramienta muy buena si la usas con respeto. Cambiar compresión, desactivar atime, poner cuotas o ajustar datasets puede dejar tu Proxmox más limpio y más predecible. Pero no es una lista de trucos para aplicar por deporte.
Mi regla es simple: miro primero, cambio una cosa, verifico después y dejo rastro. Si no puedo explicar por qué estoy cambiando una propiedad, no la cambio.
En ZFS casi todo empieza con una lectura tranquila y acaba mejor si no te vienes arriba. El storage no premia la épica. Premia la paciencia.