zpool list es el comando que uso cuando quiero una lectura rápida de ZFS sin entrar todavía en el drama completo de zpool status.
No me dice todo. Tampoco pretende hacerlo. Pero cuando estoy en un nodo Proxmox y algo empieza a oler a storage, me da cuatro datos que me importan mucho: tamaño del pool, espacio usado, espacio libre, fragmentación y salud. Con eso ya sé si puedo seguir mirando la VM de turno o si conviene dejar de culpar al pobre invitado y mirar debajo.
La web de Proxmox está bien para ver el estado general, pero para storage prefiero terminal. Menos capas. Menos colorines. Menos sensación de que todo está bien porque un panel ha decidido no gritar todavía.
El comando base no tiene misterio.
| |
Y si quiero mirar solo mi pool de Proxmox:
| |
Lo uso mucho después de un aviso raro, antes de ampliar discos, antes de mover VMs entre storages y cuando una copia de seguridad tarda más de lo normal. Es una lectura de pulso, no una operación quirúrgica.
la captura de este post#
La captura sale de un nodo real de Proxmox, pero está saneada. He quitado el hostname, he dejado un nombre genérico de pool y he mantenido los números porque son justo lo interesante. No hay IPs, dominios internos ni nombres privados.
Esta es la salida saneada que usé para generar la captura:
| |
Me gusta cruzar zpool list con pvesm status porque enseñan la misma realidad desde capas distintas. ZFS sabe del pool. Proxmox sabe del storage que presenta a VMs, contenedores, backups y plantillas. Si las dos lecturas cuentan una historia parecida, respiro un poco.
lo primero que miro: HEALTH#
La columna HEALTH es la que más llama la atención.
| |
ONLINE es lo que quieres ver. No significa que no exista ningún problema en el nodo, pero sí significa que el pool no está degradado desde el punto de vista de ZFS. Si aquí aparece DEGRADED, FAULTED, UNAVAIL o algo parecido, dejo de tocar servicios y empiezo a mirar discos, controladora, cables, logs y zpool status.
Hay una trampa bastante humana con esta columna. Cuando pone ONLINE, uno tiende a cerrar el caso demasiado pronto. Yo también lo he hecho. Pero ONLINE solo responde a una pregunta concreta: el pool está accesible y ZFS lo considera sano en ese momento. No responde a si hay latencia, si el pool está demasiado lleno, si la fragmentación empieza a pesar o si el problema viene de una capa por encima.
Por eso no uso zpool list como sentencia final. Lo uso como primera criba.
Si HEALTH está mal, ZFS manda. Si HEALTH está bien, sigo leyendo.
SIZE, ALLOC y FREE: la foto sencilla#
Estas tres columnas son bastante directas.
| |
SIZE es el tamaño bruto del pool. No lo confundas con el espacio útil que verá Proxmox para almacenar discos. En ZFS, sobre todo con RAIDZ, reservas, metadata y datasets, hay que tener cuidado con las equivalencias rápidas.
ALLOC es lo que el pool tiene asignado. En la captura son 458 GB. FREE es lo que queda libre a nivel de pool. Aquí aparecen 4.46 TB.
A simple vista, ese pool va sobrado. No está ni cerca de una zona incómoda. Eso ya descarta una familia entera de problemas. Si una VM va lenta, no puedo decir que sea porque el pool está al 92 por ciento. Si un backup falla, probablemente no es por falta de espacio en este ZFS concreto. Puede fallar por mil cosas más, claro. El homelab tiene ese talento especial para inventar formas nuevas de perderte una noche.
Cuando veo un pool muy lleno, mi actitud cambia. ZFS no lleva bien vivir permanentemente al límite. Yo intento no pasar del 80 por ciento en pools donde hay VMs activas. Si me acerco a esa zona, no espero a que Proxmox empiece a protestar. Reviso snapshots, discos viejos, VMs apagadas, backups locales y cualquier volumen que haya crecido sin avisar.
CAP: el porcentaje que miro con más mala leche#
CAP es el porcentaje de capacidad usada del pool.
| |
En la captura, 9 por ciento. Cero drama.
Esta columna me resulta más cómoda que ir haciendo cuentas con ALLOC y SIZE. Si estoy revisando varios nodos, miro CAP casi como quien mira temperatura. No necesito precisión quirúrgica en ese primer vistazo. Necesito saber si un nodo está tranquilo, cargado o peligrosamente lleno.
Mi escala mental suele ser esta.
- Menos de 60 por ciento: tranquilo
- Entre 60 y 75 por ciento: lo miro con atención si el pool mueve VMs
- Entre 75 y 85 por ciento: empiezo limpieza o planificación
- Más de 85 por ciento: no me gusta, y menos si hay escrituras constantes
No es una ley universal. Depende del tipo de pool, carga, discos y uso. Pero como regla de homelab me sirve. Prefiero ser conservador con almacenamiento. Un disco lleno no avisa con educación británica. Simplemente empieza a romper planes.
FRAG: la columna que mucha gente ignora#
La fragmentación aparece aquí:
| |
ZFS no funciona como un disco viejo de Windows donde uno se obsesionaba con desfragmentar. No vas a ejecutar un botón mágico para dejarlo bonito. Aun así, la fragmentación importa. Sobre todo en pools con muchas escrituras pequeñas, snapshots, discos virtuales que crecen y borrados frecuentes.
Un 19 por ciento no me preocupa. Es una cifra normal en un pool que se usa. Si viera 60, 70 u 80 por ciento en un pool con VMs activas y quejas de rendimiento, ya no lo ignoraría.
Aquí conviene no caer en una conclusión torpe. Fragmentación alta no significa automáticamente que ese sea el problema. Pero si se junta con poco espacio libre, discos mecánicos, muchas VMs y latencias raras, empieza a sumar puntos.
En mi caso, esta columna me sirve para contexto. Si todo lo demás está sano y FRAG está moderado, sigo buscando. Si el pool está lleno y fragmentado, empiezo a pensar en limpieza, migración o rediseño. Y si el pool es viejo, ha tenido muchas pruebas y se ha convertido en un cajón de sastre, quizá toca admitir que el problema no es un comando. Es arquitectura acumulada con demasiada alegría.
DEDUP: casi siempre quiero ver 1.00x#
La columna DEDUP suele ser aburrida, y eso está bien.
| |
En un homelab normal, quiero ver deduplicación apagada. ZFS dedup puede sonar tentador cuando tienes muchas VMs parecidas. En la práctica, para la mayoría de laboratorios caseros, es una trampa bastante cara en RAM y complejidad. No digo que nunca tenga sentido. Digo que si no sabes exactamente por qué la necesitas, probablemente no la necesitas.
1.00x me dice que no hay ahorro por deduplicación. También me tranquiliza porque no estoy pagando el coste de mantener tablas de dedup para ganar migajas.
Para ahorrar espacio prefiero compresión. lz4 suele ser una decisión mucho más sensata. Menos épica, menos peligrosa y normalmente útil.
por qué lo cruzo con pvesm status#
zpool list me habla de ZFS. pvesm status me habla de Proxmox.
| |
En la captura, Proxmox ve pve-zfs como zfspool activo, con uso del 25.25 por ciento. La cifra no coincide exactamente con CAP de zpool list porque no están midiendo lo mismo de la misma forma. Esto es normal. Una capa enseña el pool. La otra enseña el storage tal como Proxmox lo gestiona.
Lo que busco no es igualdad perfecta. Busco coherencia.
Si ZFS dice ONLINE, pero Proxmox marca el storage como inactive, tengo un problema de integración o configuración. Si ZFS dice que queda espacio, pero Proxmox enseña el storage lleno, reviso reservas, thin provisioning, datasets y cómo está calculando cada capa. Si Proxmox está sano y ZFS también, puedo dejar el storage más abajo en la lista de sospechosos.
Ese cruce evita perder tiempo. Y en un homelab, perder tiempo suele ser el verdadero coste. El hardware ya lo pagaste. Las horas a las dos de la mañana son las que duelen.
mi lectura rápida cuando una VM va lenta#
Si una VM empieza a ir rara y vive sobre ZFS, hago una pasada corta.
| |
Con zpool list miro capacidad y fragmentación. Con zpool status miro errores, discos y scrub. Con pvesm status miro si Proxmox tiene el storage activo y cuánto espacio cree que queda.
Si todo sale limpio, no digo que ZFS sea inocente para siempre. Pero bajo su prioridad. Me voy a CPU steal, RAM, IO dentro del invitado, backups en curso, snapshots, red, pvestatd, Ceph si aplica o lo que toque.
Si algo sale feo, paro. No amplío discos, no muevo VMs y no lanzo cambios grandes mientras no entienda qué pasa. Esto parece obvio escrito en frío. En caliente, cuando quieres arreglarlo rápido, no lo es tanto.
cuándo me preocupa de verdad#
Hay varias combinaciones que me hacen levantar la ceja.
Un pool con HEALTH distinto de ONLINE es prioridad alta. Ahí no hay debate.
Un pool por encima del 85 por ciento, con VMs activas y snapshots, me parece mala idea. Puede funcionar durante un tiempo, pero no me gusta vivir ahí.
Fragmentación muy alta con discos mecánicos y mucha escritura pequeña también me preocupa. No siempre puedes arreglarla de forma limpia sin mover datos, pero al menos sabes que no estás ante un misterio cósmico.
Un DEDUP distinto de 1.00x en un entorno donde nadie recuerda haber activado deduplicación me parece señal de revisar decisiones pasadas. A veces el enemigo no es el fallo. Es el experimento que hiciste hace seis meses y que olvidaste documentar.
Y luego está la incoherencia entre capas. ZFS tranquilo, Proxmox incómodo. Proxmox tranquilo, ZFS avisando. Cuando las capas no cuentan lo mismo, toca bajar un nivel y no fiarse solo de la web.
lo que no arregla este comando#
zpool list no te dice qué VM está escribiendo como si odiara tus discos. No te enseña latencia por proceso. No revisa snapshots por dataset. No valida backups. No comprueba cables. No sustituye a SMART. No entiende tu arquitectura.
Es una tabla pequeña. Ese es su encanto y su límite.
Para datasets uso zfs list. Para salud real del pool uso zpool status. Para discos físicos uso SMART o las herramientas del sistema. Para ver carga de IO tiro de iostat, iotop o métricas si las tengo bien montadas. Para Proxmox, cruzo con pvesm status, tareas recientes y logs.
Pero como primer vistazo, zpool list está muy arriba en mi lista. Entra rápido, no toca nada y te sitúa.
mi regla práctica#
Si entro en un nodo Proxmox con ZFS y no sé todavía si el storage está implicado, ejecuto zpool list antes de ponerme creativo.
No porque sea sofisticado. Justo por lo contrario. Es simple, seco y difícil de malinterpretar si sabes qué mirar.
Quiero ver ONLINE, capacidad razonable, fragmentación no absurda y dedup en 1.00x. Si eso cuadra, sigo investigando con calma. Si no cuadra, cambio el orden de prioridades y dejo de tratar el problema como si fuera una VM caprichosa.
En almacenamiento, una lectura aburrida suele ser una buena noticia. Yo no necesito que ZFS me entretenga. Necesito que no me arruine la tarde.