zpool get no tiene glamour. No te enseña una gráfica bonita, no te da una barra roja de peligro y no parece gran cosa si vienes de la interfaz de Proxmox. Precisamente por eso me gusta. Es una forma muy limpia de preguntarle al pool ZFS cómo está configurado y qué valores tiene ahora mismo, sin tocar nada y sin depender de que la web haya refrescado bien.
Yo lo uso antes de cambiar cualquier cosa en almacenamiento. También lo uso cuando tengo esa sensación rara de que algo no cuadra entre lo que creo que configuré hace meses y lo que el servidor está haciendo hoy. En un homelab eso pasa más de lo que nos gusta admitir. Montas un nodo, cambias discos, pruebas un mirror, migras una VM, haces un ajuste para salir del paso y tres meses después ya no recuerdas si autotrim estaba activado, si el pool se creó con ashift=12 o si la fragmentación ha empezado a ponerse tonta.
El comando base es este.
| |
Pero casi nunca quiero verlo todo. all mete demasiado ruido. Para una revisión rápida suelo filtrar.
| |
Y cuando quiero ver un resumen algo más amplio, tiro de egrep para quedarme con lo que necesito.
| |
No es elegante. Funciona. En storage, eso ya me parece una virtud bastante seria.
la captura de este post#
La captura está hecha con una salida saneada basada en un entorno Proxmox con ZFS. Los nombres son genéricos y los valores son realistas, pero no exponen inventario privado. No hay IPs, rutas internas ni hostnames de mi laboratorio.
Esta es la salida saneada que usé para generar la captura:
| |
Esta salida ya me da una foto bastante útil. El pool está online, tiene un 40 por ciento de ocupación, fragmentación moderada, ashift=12 fijado localmente y autotrim activado. autoreplace y failmode siguen en default.
No he cambiado nada. Solo he mirado. Eso en ZFS vale oro.
por qué miro zpool get si ya existe zpool status#
zpool status me dice si el pool está sano, qué vdevs tiene, si hay errores, si hay un scrub en marcha y si ZFS está quejándose de algo. Es el primer comando que miro cuando sospecho de discos.
zpool get contesta otra pregunta. Me dice propiedades del pool. Configuración. Valores actuales. Algunas propiedades salen calculadas, otras vienen del valor local, otras del valor por defecto. No compite con zpool status. Lo complementa.
Mi secuencia mental suele ser esta.
| |
Primero miro salud. Luego capacidad. Luego propiedades.
Si el pool está ONLINE, capacidad razonable y sin errores, ya bajo el nivel de alarma. Si además veo que las propiedades importantes tienen sentido, dejo de perseguir fantasmas y empiezo a mirar otro sitio. Muchas veces el problema no es ZFS. Es una VM saturada, un backup pisando horas malas o una expectativa demasiado optimista sobre discos pequeños.
capacity no es lo mismo que ir sobrado#
capacity parece una lectura simple. Si pone 40 por ciento, todo bien. Si pone 90 por ciento, mala pinta. Hasta ahí llegamos todos.
La trampa es que ZFS no se comporta igual cuando el pool va cómodo que cuando empieza a llenarse. A partir de cierto punto, el rendimiento puede caer y las operaciones empiezan a ser más antipáticas. Yo intento no llevar un pool de VMs muy arriba salvo que sea almacenamiento frío o algo que pueda tolerar lentitud.
En el ejemplo, capacity marca 40 por ciento.
| |
Eso me deja tranquilo. No significa que no haya problemas posibles, pero elimina una causa habitual. Si una VM va lenta con el pool al 40 por ciento y sin errores, no empiezo por borrar cosas a lo bruto. Miro I/O, snapshots, backups, memoria de la VM y procesos dentro del invitado.
Cuando veo 80 o 85 por ciento, ya cambio el tono. No me gusta tener ZFS en esa zona, especialmente si hay VMs con escritura constante. Puede sobrevivir, claro. También puedes circular con una rueda floja. No significa que sea una estrategia.
fragmentation importa, pero no la convierto en religión#
fragmentation es una propiedad que se presta mucho al drama. Ves 35 por ciento y ya parece que el pool está condenado. No siempre.
| |
En el ejemplo está en 18 por ciento. Para un pool de laboratorio con VMs, backups y pruebas, no me quita el sueño. Lo apunto mentalmente, lo comparo con lecturas anteriores y sigo.
Lo importante es no leer fragmentación aislada. Si la fragmentación sube, la capacidad está alta y además zpool iostat muestra latencias feas durante cargas normales, entonces sí empieza a tener sentido actuar. Si solo tienes una cifra sin síntomas, no desmontaría medio laboratorio por eso.
ZFS no tiene una desfragmentación mágica tipo botón. La forma real de mejorar una fragmentación mala suele pasar por mover datos fuera y volver a escribirlos, recrear datasets o replantear el pool. Eso no es una tarea de martes a las once de la noche porque te aburrías. Es cirugía.
Por eso prefiero usar zpool get fragmentation como termómetro, no como orden de trabajo.
ashift es de las cosas que quieres acertar al crear el pool#
ashift me importa mucho más de lo que aparenta.
| |
ashift=12 equivale a sectores de 4K. En discos modernos suele ser la decisión razonable. Lo relevante es que no es una propiedad que yo trate como algo para tocar alegremente después. Si está mal, el problema viene de cómo se creó el pool. Y arreglar eso suele implicar recrear, no cambiar un numerito y seguir con la vida.
Por eso me gusta verlo en revisiones. No porque vaya a editarlo, sino porque me ayuda a entender si hay una base sana. Si estoy heredando un nodo antiguo, un pool creado con prisas o una instalación que ha pasado por muchas manos, ashift es una de las primeras cosas que quiero confirmar.
La columna SOURCE también dice algo. En el ejemplo aparece local, así que el valor se fijó en el pool. Bien. Si estoy documentando el laboratorio, lo apunto. No hace falta escribir una novela, pero sí conviene saber cómo se creó el almacenamiento que sostiene tus VMs.
autotrim en SSD no es decoración#
En pools sobre SSD, autotrim es una propiedad que miro siempre.
| |
No significa que todo vaya a ser perfecto. Tampoco convierte un SSD barato en almacenamiento empresarial. Pero ayuda a que el dispositivo reciba información sobre bloques liberados. En un homelab con VMs que se crean, se borran, se mueven y se redimensionan, eso tiene bastante sentido.
Yo prefiero tenerlo activado en pools SSD, salvo que haya una razón concreta para no hacerlo. Y razón concreta no es haber leído un comentario viejo en un foro diciendo que TRIM era peligroso en 2012.
Para activarlo se usa esto.
| |
Pero aquí viene la parte importante. No lo ejecuto como reflejo. Primero miro el tipo de discos, el estado del pool, si hay carga fuerte en ese momento y si estoy en una ventana tranquila. Activar una propiedad puede ser sencillo, pero sigue siendo un cambio sobre almacenamiento. En mi cabeza, todo cambio de storage merece más respeto que cambiar el color de un dashboard.
También miro si ya está activado. Parece obvio, pero he visto muchas tardes perdidas intentando arreglar algo que ya estaba configurado como querías.
autoreplace no siempre tiene que estar activado#
autoreplace suele aparecer en off.
| |
En servidores con bahías bien identificadas y procedimientos claros, puede tener sentido activar reemplazos automáticos. En un homelab, depende muchísimo. Si tienes discos USB, adaptadores raros, etiquetas pobres o cajas donde no sabes bien qué disco es cuál, yo prefiero no automatizar demasiado.
No me molesta verlo en off. De hecho, en muchos laboratorios me parece prudente. Prefiero hacer el reemplazo de forma consciente, mirando zpool status, identificando el disco, revisando seriales y confirmando dos veces antes de tocar nada.
ZFS es muy bueno, pero no adivina que tú has conectado el disco equivocado porque estabas medio dormido.
failmode y el tipo de susto que quieres tener#
failmode define qué hace ZFS si el pool sufre un fallo crítico de I/O. En el ejemplo está en wait.
| |
No es una propiedad que toque normalmente en Proxmox doméstico. Pero sí me gusta saber qué hay. wait puede congelar operaciones esperando a que el pool vuelva. Otros modos tienen otros comportamientos. No voy a convertir esto en una clase larga porque lo importante para mí es más básico: si una VM se queda colgada durante un problema serio de storage, quiero saber si el pool está esperando, si ha fallado o si el sistema está intentando seguir como puede.
Aquí zpool get no sustituye a logs ni a zpool status. Solo me ayuda a interpretar el susto.
cómo lo uso en una revisión real#
Cuando voy a tocar un nodo Proxmox con ZFS, suelo ejecutar una revisión corta.
| |
Con eso ya sé si el pool está sano, si va lleno, si la fragmentación pinta rara, si TRIM está activado y si los datasets tienen consumos absurdos. No necesito abrir diez pestañas ni esperar a que una gráfica me cuente media verdad.
Si estoy antes de un reinicio, añado una mirada a tareas de Proxmox y backups. Si estoy antes de mover VMs, miro también el storage disponible en todos los nodos. Si estoy investigando lentitud, combino esto con zpool iostat.
La gracia está en repetir siempre una base parecida. No porque sea perfecto, sino porque reduce despistes. Y en homelab, muchos problemas no vienen de no saber. Vienen de tocar rápido una noche en la que creías que lo tenías todo en la cabeza.
Spoiler: no lo tenías todo en la cabeza.
lo que no hago con zpool get#
No uso zpool get para justificar cambios impulsivos. Ver una propiedad distinta de lo que esperaba no significa que haya que corregirla al momento. Primero entiendo por qué está así.
Tampoco comparo pools distintos como si todos debieran tener la misma configuración. Un pool de SSD para VMs no es igual que un pool de discos grandes para backups. Un nodo pequeño de pruebas no necesita las mismas decisiones que un servidor donde dependen servicios de verdad.
Y no uso la salida como sustituto de documentación. Si descubro algo importante, lo apunto. Un README cutre en el repo del homelab vale más que una memoria heroica que se evapora cuando tienes sueño.
mi lectura rápida#
Si tengo que resumir cómo leo zpool get, lo hago así.
health: confirma si el pool se declara sanocapacity: me dice si ZFS empieza a ir apretadofragmentation: me da una pista, no una sentenciaashift: me dice si el pool nació con una base razonableautotrim: importante en SSDautoreplace: depende del tipo de laboratorio y del procedimientofailmode: ayuda a entender comportamientos feos en fallos seriosSOURCE: me dice si el valor viene fijado, heredado o por defecto
No es una lista espectacular. Es una lista útil.
cierre#
zpool get es uno de esos comandos que no arreglan nada y aun así evitan muchos errores. En Proxmox me sirve para separar intuición de realidad. Antes de tocar almacenamiento, miro. Antes de culpar a ZFS, miro. Antes de asumir que una propiedad está como yo recuerdo, miro.
La terminal no siempre tiene razón sobre lo que deberías hacer después, pero sí suele tener razón sobre lo que hay ahora mismo. Y en un homelab con Proxmox, esa diferencia te puede ahorrar una noche bastante miserable.