ZFS es una de esas piezas del homelab que me encantan y me dan respeto al mismo tiempo. Me encanta porque cuando está bien montado te da snapshots, checksums, scrubs, compresión y una sensación bastante agradable de tener el disco bajo control. Me da respeto porque cuando algo huele mal en ZFS no conviene ponerse creativo.
En Proxmox uso zpool status como una lectura de pulso. No es el único comando que miro, pero sí suele ser el primero cuando un nodo empieza a comportarse raro y sospecho del almacenamiento. Una VM tarda más de lo normal en arrancar, un backup se queda pesado, una migración se vuelve lenta, un contenedor se queja del disco o la interfaz web enseña un storage amarillo. Antes de abrir diez pestañas, entro por SSH y miro el pool.
| |
La salida no parece emocionante. Justo por eso me gusta. Estado del pool, último scrub, discos, errores de lectura, escritura y checksum. Pocas cosas, pero bastante decisivas.
la captura de este post#
La captura sale de un nodo real de Proxmox, con nombres de discos saneados. No enseño rutas internas, identificadores de hardware ni nombres del laboratorio. El punto aquí es leer la estructura, no presumir de inventario.
Esta es la salida saneada que usé para generar la captura:
| |
Es una foto tranquila. Pool ONLINE, último scrub con cero errores, discos a cero en READ, WRITE y CKSUM, y sin errores conocidos de datos. Es la salida que quiero ver antes de descartar el storage como sospechoso principal.
ONLINE no significa que pueda dejar de mirar#
La primera línea que mira todo el mundo es state.
| |
Bien. El pool está online. Eso no significa que todo vaya perfecto, pero sí significa que ZFS no está diciendo que el pool esté degradado, suspendido, exportado o directamente roto.
Aun así, ONLINE es solo el principio. He visto demasiadas veces a alguien quedarse ahí y cerrar el caso. Si el pool está online, entonces no es disco. Ojalá. Un pool puede estar online y tener errores corregidos, un scrub viejo, fragmentación absurda, latencias malas por debajo o un disco que empieza a fallar de forma intermitente.
Yo lo leo como una puerta de entrada. Si está ONLINE, respiro un poco. Si no lo está, dejo de tocar VMs y me pongo serio con almacenamiento.
Los estados que me hacen parar son los obvios.
| |
Si aparece cualquiera de esos, no sigo con la hipótesis de que igual es la VM. Primero storage. Luego ya veremos.
el scrub cuenta más de lo que parece#
La línea de scan es una de mis favoritas.
| |
Aquí quiero saber tres cosas.
Primero, cuándo fue el último scrub. Si hace meses que no se ejecuta, el pool puede estar aparentemente sano, pero no tengo una validación reciente de los datos. En un homelab pequeño no hace falta obsesionarse, pero dejar ZFS sin scrubs durante meses me parece pedir una sorpresa.
Segundo, si reparó algo. repaired 0B es lo que quiero ver. Si reparó datos, no entro en pánico automáticamente. ZFS está precisamente para detectar y corregir ciertas cosas. Pero sí lo apunto. Un evento aislado puede ser ruido. Eventos repetidos en el mismo disco ya son otra historia.
Tercero, si terminó con errores. with 0 errors es la línea aburrida que quiero. Si hay errores, miro más. No hay heroicidad aquí. Un pool que reporta errores merece atención antes de seguir apilando servicios encima.
En mi caso suelo programar scrubs periódicos y revisar que se hayan ejecutado. No para sentirme administrador de datacenter, sino porque los discos no avisan con educación. A veces se limitan a empezar a mentir.
la tabla de discos es donde ZFS deja de ser abstracto#
La parte que más me interesa es la tabla.
| |
Aquí ZFS baja al suelo. Ya no hablamos de un storage genérico. Hablamos del pool, del vdev y de cada disco.
En esta captura hay un raidz1-0 con seis discos. No voy a convertir esto en una defensa religiosa de RAIDZ1, RAIDZ2, mirrors o layouts. Cada diseño tiene su sitio y sus renuncias. Lo importante para este post es que, cuando miro el estado, quiero saber qué nivel está afectado si algo se tuerce.
Si falla un disco, lo veré en la fila del disco. Si falla el vdev, el problema ya no es una pieza suelta. Si el pool tiene errores arriba pero los discos están limpios, toca mirar con más cuidado porque puede haber historia previa, errores ya limpiados o eventos que no se entienden con una lectura rápida.
La tabla también me ayuda a recordar que ZFS no es magia. El pool depende de discos concretos. Si esos discos viven en un mini PC con una controladora rara, cables SATA reguleros, temperatura alta o una caja USB que no debería estar sosteniendo nada serio, el comando puede darte la primera señal de que el diseño físico se está vengando.
READ, WRITE y CKSUM#
Estas tres columnas son pequeñas, pero mandan.
| |
READ apunta a errores al leer. WRITE apunta a errores al escribir. CKSUM apunta a errores de checksum, que son especialmente interesantes porque ZFS comprueba que lo leído coincide con lo que esperaba.
Ceros en todo es lo ideal.
Un número distinto de cero no siempre significa desastre inmediato. Puede ser un cable que hizo una tontería, un disco que tuvo un mal día o un evento ya resuelto. Pero yo no lo trato como decoración. Si veo errores, miro cuándo aparecieron, si aumentan y si se concentran en un disco.
La pregunta importante no es solo si hay errores. Es si siguen creciendo.
Por eso, cuando algo me preocupa, repito la lectura.
| |
Si los contadores suben mientras el nodo trabaja, dejo de mirar a otro lado. Y si suben durante un scrub o bajo carga de backup, aún más.
la línea de errores conocidos#
Al final aparece una frase que me gusta ver tal cual.
| |
Es una línea sobria. No promete que el universo esté en orden. Dice que ZFS no conoce errores de datos. Para una comprobación rápida, me vale.
Si aquí aparece una lista de archivos afectados o mensajes más feos, cambia el plan. Ya no estoy haciendo una revisión preventiva. Estoy diagnosticando daño o al menos inconsistencia. En ese caso no improviso comandos de reparación porque sí. Primero leo, saco copia de lo que pueda, miro el histórico y decido con calma.
El peor momento para aprender ZFS es cuando tienes un pool gritando. Por eso prefiero hacer estas lecturas cuando todo está bien. Así sé qué pinta tiene la normalidad.
zpool list completa la lectura#
Después de zpool status, suelo mirar zpool list.
| |
En la captura sale esto.
| |
Esto no sustituye al estado, pero me da contexto. Tamaño, espacio usado, espacio libre, fragmentación, capacidad y deduplicación.
CAP al 4 por ciento es una vida cómoda. Un pool lleno empieza a comportarse peor. No hace falta esperar al 99 por ciento para sufrir. En ZFS me gusta dejar margen. Mucho margen si el pool sostiene VMs.
FRAG al 17 por ciento no me preocupa en esta foto. Si veo valores altos en pools con muchas escrituras pequeñas, snapshots y discos moviéndose todo el día, lo apunto. La fragmentación no siempre es el enemigo principal, pero puede explicar por qué un pool sano en estado se siente más lento de lo que debería.
DEDUP en 1.00x también me dice algo. Deduplicación no está aportando ahorro. En la mayoría de homelabs no la activaría alegremente. Consume memoria y complica la vida. Si necesitas ahorrar espacio, casi siempre prefiero compresión antes que deduplicación.
cuando zpool status me deja seguir#
Si veo ONLINE, scrub reciente con cero errores, contadores a cero y No known data errors, no declaro victoria universal. Solo saco el storage ZFS de la lista de sospechosos fuertes.
Entonces sigo por capas.
Si el problema es una VM, miro qm status, qm config, qm pending y tareas recientes.
Si el problema es rendimiento, miro carga del nodo, IO wait y si hay backups, scrubs o replicaciones corriendo.
Si el problema es Proxmox como tal, miro servicios como pvestatd, pvedaemon o pveproxy.
Si el problema huele a red de storage, miro bridges, MTU y conectividad.
El valor de zpool status es precisamente ese. Me permite no hacer teatro. Si ZFS está sano, sigo. Si ZFS no está sano, paro.
cuando no me deja seguir#
Si el pool aparece degradado, con errores o con un disco raro, mi rutina cambia bastante.
Primero guardo la salida.
| |
Luego miro si hay eventos recientes.
| |
Después reviso SMART si los discos lo permiten.
| |
No siempre hay una respuesta limpia. Algunos discos detrás de ciertas controladoras no exponen SMART como deberían. Algunas cajas externas son un poema malo. Por eso me gusta que Proxmox tenga el storage serio en hardware que no esconda demasiado.
Si hay un disco claramente malo, no intento convencerme de que aguanta un poco más porque hoy me viene mal. Esa frase es el inicio de demasiadas tardes perdidas. Cambio el disco, resilver con calma y vigilo.
Si los errores son de checksum y no hay un disco obvio, miro cables, controladora, RAM y temperatura. ZFS detecta el síntoma. La causa puede estar en varias capas.
lo que no hago con este comando#
No uso zpool status como excusa para no tener backups.
ZFS no es backup. RAIDZ no es backup. Un scrub limpio no es backup. Esto ya está repetido hasta el cansancio, pero merece seguir repitiéndose porque en homelab todos hemos pecado alguna vez de optimismo barato.
Un pool sano puede perder datos por borrado humano, ransomware, bug, mala migración, comando equivocado o una actualización con mala suerte. ZFS ayuda muchísimo, pero no te salva de ti mismo.
Tampoco uso zpool clear a ciegas solo para dejar la salida bonita.
| |
Ese comando puede tener sentido después de entender y resolver la causa de los errores. Usarlo antes es maquillaje. Y el maquillaje en storage me parece una idea bastante mala.
mi lectura rápida#
Cuando tengo prisa, mi lectura mental va así.
| |
Si todo eso cuadra, sigo con otra capa.
Si algo no cuadra, dejo de fingir que el problema está arriba. La VM puede estar fallando, claro. Proxmox puede estar raro. La red puede tener su propia fiesta. Pero si ZFS enseña una señal mala, empiezo por ahí.
cierre#
zpool status no es un comando glamuroso. Mejor. Los comandos de diagnóstico buenos suelen tener poco teatro.
En Proxmox me sirve para responder una pregunta muy concreta antes de tocar más cosas. ¿El pool ZFS está sano según ZFS? Si la respuesta es sí, avanzo. Si la respuesta es no, bajo el ritmo y trato el storage como el centro del problema.
La gracia está en mirarlo cuando todo va bien, no solo cuando ya tienes medio laboratorio ardiendo. Así aprendes la pinta de una salida limpia y, cuando aparece una línea rara, no tienes que adivinar si eso siempre estuvo ahí.