Un desmontaje lento crea una montura de gato de Schrödinger
- No puede saber si el dispositivo está realmente desmontado o no
- El sistema de archivos "desmontado" permanece accesible en algunas circunstancias
- El sistema de archivos "desmontado" no es accesible en algunas circunstancias
Existe una falsa sensación de seguridad : parece que el sistema de archivos se ha desmontado, pero en realidad solo se ha ocultado del espacio de nombres / jerarquía de archivos.
- Los procesos aún pueden escribir a través de descriptores de archivos abiertos
- Los archivos nuevos o existentes se pueden abrir para escritura mediante procesos con un directorio de trabajo dentro del punto de montaje a través de nombres de ruta relativos
Esto significa que si umount -l /media/hddya no podrá acceder /media/hdd/dir/file(nombre de ruta absoluto) pero si tiene un proceso con directorio de trabajo /media/hdd, aún podrá crear nuevos procesos que pueden leer / escribir ./dir/file(nombre de ruta relativo).
Si intenta desmontar el dispositivo, recibirá un mensaje confuso:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
Esto hace que parezca que el dispositivo no se ha montado, pero aún puede haber procesos que escriben en el disco.
Dado que hay varias situaciones no obvias que pueden causar que umount se bloquee , es posible que el sistema de archivos aún no se desmonte aunque lsof +f -- /dev/deviceno muestre nada.
Nunca sabrá si el sistema de archivos realmente se desmonta. No hay forma de averiguarlo.
Dispositivos extraíbles
Si haces umount -lun disco extraíble, estás en el limbolandia: no puedes estar seguro de que todos los datos pendientes se hayan escrito en el disco.
Lo mejor que puede hacer después de un umount -les asegurarse de que toda la escritura se complete y evitar futuras escrituras , pero aún no puede garantizar que se haya desmontado.
Con los dispositivos extraíbles, si el dispositivo no está desmontado correctamente, puede producirse un comportamiento extraño la próxima vez que se conecte:
El dispositivo obtendrá un nombre de dispositivo incrementado, es decir, se /dev/sdbconvierte en /dev/sdc. Los mensajes de registro del kernel aún pueden referirse a /dev/sdbpesar de que ese dispositivo ya no existe como un archivo debajo /dev. (La única forma en que sé resolver esto es reiniciando).
btrfs corrupción puede resultar. btrfs espera que solo un sistema de archivos con un UUID determinado esté presente a la vez. El núcleo todavía ve el mismo UUID disponible en el dispositivo fantasma y el nuevo dispositivo. (Tuve que reconstruir mi disco duro de respaldo btrfs).
systemd gotchas
umount(2)varias veces recientemente. Solo dice "Realice un desmontaje diferido: haga que el punto de montaje no esté disponible para nuevos accesos, desconecte inmediatamente el sistema de archivos y todos los sistemas de archivos montados debajo de él y de la tabla de montaje, y realmente realice el desmontaje cuando el punto de montaje deje de estar ocupado ". Pero desafortunadamente, esto es menos detallado incluso de lo que ha proporcionado.umount(8)dice que un sistema de archivos está ocupado "por ejemplo, cuando hay archivos abiertos en él, o cuando algún proceso tiene su directorio de trabajo allí, o cuando un archivo de intercambio está en uso". Eso no suena como una lista definitiva, pero probablemente sea tan bueno como pueda encontrar.