¿Por qué es perezoso MNT_DETACH o `umount -l` inseguro / peligroso?

He leído en algunos lugares que umount -lno es seguro:

En una respuesta de @cas :

no use umountla --lazyopción si le importa cuándo se puede desconectar la unidad externa de forma segura

Un comentario de @frostschutz :

umount --lazyno es seguro y no se puede hacer seguro. [...]

Este util-linux comentario de Ruediger Meier :

Debe evitar usar umount -len absoluto. Simplemente elimine todos los procesos que está utilizando /tmp/mountpointy luego desmonte sin opción -l.

¿Por qué es umount -linseguro / peligroso?

¿Hay alguna manera de hacerlo seguro?

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

• Parece que un desmontaje diferido o MNT_DETACHes causado por el uso x-systemd.mount-timeout=en /etc/fstabo el uso TimeoutIdleSec=de un archivo de Automount .

• Evite las systemdopciones anteriores especialmente está utilizando btrfs. Aprendí de la amarga experiencia (ver la referencia de btrfs arriba).