zfs unmount es uno de esos comandos que parecen demasiado simples para merecer un post. Desmonta un dataset y listo. Fin. Cierra la puerta al salir.
La realidad en Proxmox es menos limpia. Un dataset puede estar montado porque lo usa una VM, porque lo usa un contenedor, porque hay una tarea de backup mirando dentro, porque una shell se quedó abierta en ese directorio, porque un servicio tiene un archivo bloqueado o porque tú mismo hiciste una prueba rápida hace dos noches y ahora no recuerdas ni el motivo ni el café que la provocó.
Por eso no trato zfs unmount como un botón de apagar. Lo trato como una operación pequeña, pero con contexto. Antes de desmontar miro qué dataset es, dónde está montado, quién lo usa y si Proxmox espera encontrar algo ahí. Si no hago esa parte, el comando que debería ordenar el sistema puede convertirse en una manera muy elegante de romper una tarea que iba bien.
El comando base es este.
| |
Y si quiero desmontar por punto de montaje:
| |
Yo prefiero usar el nombre del dataset cuando lo tengo claro. Me obliga a saber qué estoy tocando. El punto de montaje puede engañar más, sobre todo si he estado probando mountpoint, canmount o datasets heredados.
la captura de este post#
La captura usa una salida saneada de un nodo Proxmox con ZFS. He cambiado nombres de pool, datasets y rutas para no enseñar estructura real. El patrón sí es el que uso: confirmar montaje, ver quién lo ocupa, desmontar y comprobar que ya no aparece.
La salida de ejemplo es esta.
| |
Lo importante de esa salida no es el desmontaje. Es el fuser antes. Si hay algo dentro del dataset, quiero verlo antes de decidir.
cuándo uso zfs unmount#
No lo uso todos los días. En un Proxmox tranquilo, los datasets deberían montarse y desmontarse solos según su configuración y según lo que haga el sistema. Si estoy usando zfs unmount, normalmente hay una razón concreta.
La primera situación es un punto de montaje que se ha quedado raro. Por ejemplo, un dataset que aparece montado pero no debería estarlo, o un directorio que ya no tiene sentido después de mover datos. Antes de cambiar propiedades, me gusta dejar claro el estado actual.
La segunda es una prueba con datasets auxiliares. Creo datasets para plantillas, dumps, pruebas de compresión o clones temporales. Cuando termino, no siempre quiero destruirlos en caliente. A veces los desmontar primero me permite revisar con calma qué depende de ellos.
La tercera es una limpieza después de tocar mountpoint o canmount. Estas propiedades son útiles, pero también son una buena forma de confundirte si vas rápido. Puedes tener un dataset con mountpoint=legacy, otro con canmount=off, otro heredando ruta del padre y otro montado donde no esperabas.
La cuarta es cuando quiero comprobar si un servicio depende de una ruta. Si desmontar falla porque el dataset está ocupado, ya tengo una pista. No es una prueba científica completa, pero en un homelab a veces la pista corta vale más que media hora de paneles.
Lo que no hago es usarlo para apagar problemas a golpes. Si una VM va lenta, desmontar datasets al azar no es diagnóstico. Es vandalismo con prompt de root.
primero miro el dataset#
Antes de desmontar, quiero saber tres cosas: nombre, punto de montaje y estado.
| |
La columna MOUNTED me ahorra tonterías. Si ya pone no, el problema no es que el dataset siga montado. Puede ser una ruta vacía, una propiedad mal heredada, una entrada en Proxmox que apunta a donde no toca o una expectativa mía que no coincide con la realidad.
También miro propiedades si la situación huele rara.
| |
mountpoint dice dónde debería montarse. canmount dice si ZFS puede montarlo automáticamente o no. Los valores que más suelo ver son on, off y noauto.
on es el caso normal. El dataset puede montarse.
off significa que no se monta, aunque puede servir como contenedor de propiedades para hijos. Esto se usa bastante en jerarquías donde el padre organiza y los hijos sí montan.
noauto permite montaje manual, pero evita el montaje automático. Me gusta para datasets de prueba o recuperación, donde no quiero que aparezcan solos tras reiniciar.
Si no miro esto antes, puedo perder tiempo desmontando algo que volverá a montarse por configuración, o intentando montar algo que está pensado para no montarse.
luego miro quién lo está usando#
Este paso es el que separa una operación limpia de una pequeña desgracia.
| |
También uso lsof si quiero más detalle.
| |
Si aparece una shell, cierro esa shell o salgo del directorio. Si aparece un proceso claro, miro qué es. Si aparece una tarea de Proxmox, paro y reviso antes de tocar nada. No me compensa desmontar un dataset que está usando un backup, una restauración, una migración o un contenedor.
El caso más tonto es también el más común: estoy dentro del directorio.
| |
Luego intento desmontar y ZFS me responde que está ocupado. No es ZFS siendo difícil. Soy yo sentado encima de la caja que intento mover.
La solución suele ser tan absurda como esto.
| |
Me gusta contar estas cosas porque en los posts técnicos parece que todo el mundo vive en un laboratorio perfecto. En la vida real, media administración de sistemas consiste en descubrir que el idiota eras tú, pero rápido.
desmontar no borra datos#
Esto conviene dejarlo claro. zfs unmount no destruye el dataset. No borra snapshots. No elimina zvols. No vacía el contenido. Solo quita el dataset del árbol de directorios.
Después de desmontar, el dataset sigue existiendo.
| |
Si quiero volver a montarlo:
| |
Esa reversibilidad es cómoda, pero no debería volvernos descuidados. Si Proxmox tiene un storage configurado sobre esa ruta, al desmontarlo el storage puede aparecer vacío, inaccesible o raro. No has borrado los datos, pero sí has quitado el camino por el que Proxmox los veía.
Por eso miro pvesm status cuando el dataset forma parte del almacenamiento que Proxmox conoce.
| |
Si el storage sale activo antes y después, bien. Si cambia de estado, ya sé que el desmontaje afecta a la capa de Proxmox y no solo a ZFS.
cuidado con VMs y contenedores#
En Proxmox hay dos mundos distintos que se mezclan fácil.
Un dataset montado como directorio puede contener ISOs, backups, plantillas, dumps o datos auxiliares. Ahí zfs unmount tiene una lectura bastante directa.
Un zvol usado como disco de VM no se desmonta igual porque no es un sistema de archivos montado en una ruta normal. Es un bloque. Si estoy mirando discos de VM, normalmente uso zfs list -t volume, qm config, qm status y herramientas de Proxmox antes de tocar nada.
| |
No quiero confundir dataset con zvol. Parece básico, pero cuando llevas veinte minutos mirando nombres como vm-120-disk-0, subvol-105-disk-0 y templates, el cerebro empieza a hacer descuentos peligrosos.
Los contenedores LXC también merecen cuidado. Un rootfs de LXC puede vivir como subvolumen en ZFS. Si desmontas algo que el contenedor usa, puedes dejarlo tieso o provocar errores raros. Antes de tocar un contenedor miro:
| |
Si está encendido y usa ese dataset, no improviso. Paro el contenedor de forma normal si toca hacerlo, o espero a una ventana tranquila.
cuándo uso -f y por qué intento no hacerlo#
Existe el desmontaje forzado.
| |
No me gusta usarlo salvo que tenga bastante claro qué está pasando. El -f puede tener sentido si un proceso muerto dejó algo raro, si una sesión remota quedó colgada o si estás limpiando un entorno controlado. Pero como reflejo automático es mala costumbre.
Si un dataset está ocupado, normalmente quiero saber por quién. Forzar porque molesta es exactamente la clase de decisión que parece eficiente a las dos de la mañana y luego te roba el sábado.
Mi orden mental es este.
- Miro
zfs list. - Miro
zfs get mountpoint,canmount. - Miro
fuserolsof. - Salgo del directorio si soy yo.
- Reviso Proxmox si el dataset está conectado a storage, VM o LXC.
- Desmonto sin forzar.
- Solo uso
-fsi el bloqueo está entendido.
No es burocracia. Es higiene.
qué hago si falla#
Si zfs unmount falla con dataset is busy, no repito el comando cinco veces como si ZFS fuese a cambiar de opinión por cansancio.
Primero miro procesos.
| |
Luego miro si hay shells abiertas.
| |
Si hay servicios usando esa ruta, paro el servicio de forma normal. Si hay una tarea de Proxmox, voy a tareas recientes y miro qué estaba ocurriendo. Si es una VM o un LXC, uso qm o pct para entenderlo.
También compruebo montajes anidados. A veces el dataset no está ocupado por algo dentro, sino porque debajo hay otro montaje.
| |
Si hay un hijo montado dentro, desmontar el padre puede fallar o no tener el efecto que espero. En ese caso ordeno la jerarquía. Primero hijos, luego padre. Sin drama.
mi regla práctica#
Para mí, zfs unmount es seguro cuando puedo responder a cuatro preguntas.
- Qué dataset voy a desmontar.
- Dónde está montado.
- Quién lo está usando.
- Qué espera Proxmox encontrar ahí.
Si una de esas respuestas está borrosa, paro. No porque el comando sea peligroso por sí mismo, sino porque el contexto puede serlo.
ZFS no suele romperse por comandos sencillos. Se rompe por comandos sencillos ejecutados con demasiada seguridad y poca información. Esa frase debería venir pegada en algunos racks, junto a la etiqueta de no tirar del cable equivocado.
cierre#
zfs unmount no es espectacular. No tiene la épica de recuperar un pool ni la satisfacción de ver un scrub limpio. Es una herramienta pequeña para poner orden en datasets y puntos de montaje.
En Proxmox la uso con respeto porque el storage rara vez vive aislado. Siempre hay una VM, un contenedor, una tarea, un backup o una decisión anterior metida en medio. Desmontar bien consiste menos en saber el comando y más en saber cuándo no usarlo todavía.
Mi versión corta: miro, confirmo, desmonto y verifico. Si algo está ocupado, averiguo por qué. Forzar es el último recurso, no el primer reflejo.
Aburrido, sí. También es justo como me gusta que sea el storage.