zfs list es el comando que uso cuando pvesm status ya se me queda corto.
Proxmox te dice que un storage está activo, cuánto ocupa y qué porcentaje queda libre. Eso está bien para una foto rápida. Pero cuando quieres saber qué está comiendo espacio dentro de un pool ZFS, necesitas bajar un nivel. Ahí entra zfs list.
Lo uso para responder preguntas muy concretas. Qué datasets existen. Qué discos de VM viven en el pool. Qué subvolúmenes de LXC ocupan más de lo esperado. Qué volumen tiene una reserva rara. Qué dataset aparece cuando nadie lo esperaba. Y, sobre todo, si el problema de espacio es real o si estoy mirando una cifra agregada sin contexto.
El comando base es sencillo.
| |
En Proxmox suelo acotarlo un poco más.
| |
Ese formato me da una tabla bastante legible. No necesito todas las propiedades de ZFS para una primera lectura. Necesito nombre, usado, disponible, referencia y punto de montaje. Con eso ya puedo orientarme.
la captura de este post#
La captura viene de un nodo real de Proxmox y está saneada. He cambiado identificadores concretos por nombres genéricos y he dejado tamaños aproximados. Lo importante aquí no es el inventario exacto, sino la forma de leer datasets, subvolúmenes y discos de VM.
Esta es la salida saneada que usé para generar la captura:
| |
Esta tabla parece más seca que la web, pero a mí me cuenta más. Veo el dataset raíz, veo subvolúmenes de contenedores LXC y veo zvols de VMs. También veo una diferencia importante entre USED y REFER, que es donde mucha gente se lía.
NAME: leer la forma del almacenamiento#
La columna NAME ya te dice bastante.
| |
En Proxmox, los contenedores LXC suelen aparecer como subvolúmenes. Las VMs suelen aparecer como volúmenes ZFS, normalmente zvols. Esa diferencia importa porque no se comportan igual, no se montan igual y no siempre los inspeccionas con las mismas herramientas.
Cuando veo subvol, pienso en LXC. Cuando veo vm-xxx-disk-y, pienso en disco de VM. No necesito abrir la web para ubicarme. Si el nombre tiene buena pinta y coincide con lo que espero, sigo. Si aparece un volumen de una VM que creía borrada, ya tengo una tarea de limpieza pendiente.
Aquí conviene recordar una cosa básica: el número de VMID no te cuenta la historia completa. Puede haber discos antiguos, volúmenes sin usar, restauraciones a medias o pruebas que dejaron restos. Por eso no borro nada solo porque el nombre me suene viejo. Primero cruzo con Proxmox.
| |
Borrar storage por intuición es una forma bastante eficiente de fabricar una tarde horrible.
USED no siempre significa lo que crees#
La columna USED dice cuánto espacio está usando ese dataset teniendo en cuenta hijos, snapshots, reservas y otros detalles de ZFS.
| |
Aquí el volumen aparece con 243 GB usados, pero REFER marca 85.2 GB. Esa diferencia no es un error. ZFS distingue entre espacio usado por el dataset en conjunto y espacio referenciado directamente por ese dataset.
Esta es una de las razones por las que zfs list me parece tan útil. La web puede enseñarte un disco de cierto tamaño y Proxmox puede mostrarte una ocupación agregada, pero ZFS te enseña detalles que explican por qué las cuentas no cuadran a simple vista.
Si USED es muy alto y REFER bastante menor, empiezo a pensar en snapshots, clones, reservas o hijos. No asumo automáticamente que el invitado tiene 243 GB de archivos. Puede ser más sutil.
Para investigar más, cambio de comando.
| |
No suelo empezar por ahí porque genera más ruido. Pero cuando USED y REFER no cuadran, merece la pena.
REFER: lo que el dataset referencia directamente#
REFER es una columna que me gusta mirar con calma.
| |
En términos prácticos, me ayuda a distinguir entre lo que parece ocupar el objeto y lo que ZFS está contando alrededor. En un zvol de una VM, REFER suele acercarme más a lo que ese volumen está referenciando ahora mismo. En un subvolumen de LXC, también me sirve para ver si un contenedor se ha ido de madre.
No es una traducción perfecta a “lo que ves dentro del sistema operativo invitado”. Si dentro de Linux haces df -h, puedes ver otra cosa. Thin provisioning, bloques liberados que no han sido descartados, snapshots y comportamiento del filesystem invitado pueden cambiar la lectura.
Por eso me gusta comparar capas.
Dentro de la VM:
| |
En Proxmox:
| |
En ZFS:
| |
Tres capas. Tres verdades parciales. Cuando encajan, perfecto. Cuando no, al menos sabes dónde empezar a tirar.
AVAIL: disponible para ese dataset, no una promesa mágica#
AVAIL muestra espacio disponible para el dataset.
| |
En la captura parece todo muy cómodo. Hay teras libres. Pero no lo leo como carta blanca para ampliar discos sin pensar. Depende de cuotas, reservas, estructura del pool, uso futuro y margen operativo.
En un homelab pequeño, es muy tentador ampliar discos porque “total, queda sitio”. Lo he hecho. Luego descubres que el problema no era el tamaño del disco, sino logs creciendo, backups locales mal puestos, una aplicación escribiendo caché sin límite o snapshots acumulados. Si solo amplías, compras tiempo. A veces está bien. Otras veces solo tapas el olor.
Antes de ampliar un disco, me hago tres preguntas.
- El invitado necesita espacio de verdad o está reteniendo basura
- Hay snapshots que explican la diferencia de uso
- El pool tiene margen suficiente para seguir sano después del cambio
Si las respuestas son razonables, amplío. Si no, investigo.
MOUNTPOINT: por qué unas líneas tienen ruta y otras no#
En la captura, los subvolúmenes tienen punto de montaje.
| |
Los discos de VM aparecen con -.
| |
Esto desconcierta un poco al principio. No todos los objetos ZFS se montan como directorios. Un zvol es un dispositivo de bloque. Proxmox lo usa como disco para una VM. No esperes verlo como una carpeta normal donde entrar con cd.
Los subvolúmenes de LXC sí aparecen montados como datasets. Eso hace que ciertas inspecciones sean más directas, aunque igualmente hay que tener cuidado. Que puedas mirar dentro no significa que debas tocar archivos a mano alegremente.
Mi regla es sencilla. Para diagnosticar, mirar está bien. Para modificar datos de un contenedor o VM desde el host, mucha prudencia. Si puedo entrar por el sistema invitado y hacer las cosas desde ahí, suelo preferirlo.
cómo encuentro quién se está comiendo el pool#
Cuando el pool crece y no sé por qué, empiezo ordenando por uso.
| |
Ese sort no siempre queda perfecto con unidades mezcladas, pero para una primera pasada ayuda. Si quiero algo más limpio, saco tamaños en bytes.
| |
Ahí ya no hay discusión con G, M o T. Ordeno por números reales.
Cuando detecto un volumen grande, no lo borro. Lo identifico. Miro si pertenece a una VM activa, si tiene snapshots, si hay backups recientes y si Proxmox lo sigue referenciando.
| |
La limpieza buena es aburrida. Confirmar, confirmar otra vez y borrar solo cuando entiendes qué estás borrando. La limpieza emocionante queda muy bien hasta que tienes que restaurar algo que no pensabas haber tocado.
snapshots: el sospechoso habitual#
Cuando USED sube y el invitado no parece tener tantos datos, miro snapshots.
| |
Los snapshots son maravillosos hasta que dejas de acordarte de que existen. En Proxmox puedes tener snapshots manuales, snapshots de pruebas, herramientas externas y retenciones que parecían prudentes hace meses. Todo suma.
No tengo nada contra los snapshots. Al contrario. Me han salvado más de una vez. Pero hay que tratarlos como copias temporales, no como un cementerio infinito de decisiones pasadas.
Si un dataset crece sin explicación, usedbysnapshots suele poner orden.
| |
Si el espacio lo retienen snapshots, borrar archivos dentro de la VM no va a liberar lo que esperas. Esa es una de esas lecciones que se aprenden una vez y luego ya no se olvidan.
cruzar con Proxmox antes de limpiar#
Después de mirar ZFS, vuelvo a Proxmox.
| |
Quiero saber si los volúmenes que he visto pertenecen a algo vivo. Si una VM está apagada desde hace meses pero sigue siendo importante, no la toco. Si un volumen parece huérfano, busco contexto. Si hay un disco unused en la configuración, lo trato como evidencia, no como basura automática.
Para una VM concreta:
| |
Para un contenedor:
| |
Solo cuando ZFS y Proxmox cuentan la misma historia me planteo limpiar. Y aun así, antes de borrar, prefiero tener backup reciente y saber qué camino de vuelta tengo.
errores típicos que intento evitar#
El primero es confundir tamaño provisionado con espacio usado. Un disco virtual puede tener 200 GB asignados y no estar ocupando 200 GB reales en ZFS. También puede pasar lo contrario en ciertas lecturas si hay snapshots o reservas.
El segundo es borrar volúmenes por nombre. Que algo se llame vm-204-disk-1 no significa que sea basura. Significa que hay que mirar qué es la VM 204 o qué fue en su momento.
El tercero es fiarse solo de df -h dentro del invitado. Esa salida te dice lo que ve el sistema operativo, no necesariamente lo que ZFS está reteniendo por debajo.
El cuarto es olvidarse de snapshots. En ZFS, borrar datos dentro de una VM con snapshots antiguos puede liberar bastante menos de lo que esperabas.
El quinto es ampliar discos sin preguntarse por qué crecieron. A veces hace falta. Otras veces estás premiando a una aplicación mal configurada.
mi rutina corta#
Cuando necesito entender un pool ZFS en Proxmox, hago esto.
| |
Si algo no cuadra, profundizo.
| |
No es una rutina elegante. Es una rutina que evita tonterías. En almacenamiento, eso vale mucho.
mi regla práctica#
Uso zfs list cuando quiero dejar de hablar de “el storage” como si fuera una nube abstracta y empezar a ver objetos concretos.
Datasets. Subvolúmenes. Zvols. Discos de VM. Contenedores. Snapshots. Espacio referenciado. Espacio retenido.
Ahí es donde los problemas dejan de sonar genéricos. Ya no es “Proxmox ocupa mucho”. Es un volumen concreto, un snapshot concreto, una VM concreta o una decisión antigua que sigue cobrando alquiler.
zfs list no arregla nada por sí solo, pero te quita niebla. Y en un homelab con Proxmox, quitar niebla ya es medio trabajo.