Perché pigro MNT_DETACH o `umount -l` non è sicuro / pericoloso?

Ho letto in alcuni punti che umount -lnon è sicuro:

In una risposta di @cas :

non usare l umount' --lazyopzione se ti interessa quando è possibile scollegare in modo sicuro l'unità esterna

Un commento di @frostschutz :

umount --lazynon è sicuro e non può essere reso sicuro. [...]

Questo util-linux commento di Ruediger Meier :

Dovresti evitare di usare umount -laffatto. Basta uccidere tutti i processi che stanno usando /tmp/mountpointe quindi smontare senza opzione -l.

Perché umount -lnon è sicuro / pericoloso?

C'è un modo per renderlo sicuro?

Uno smontaggio pigro crea una cavalcatura per gatti di Schrödinger

• Non è possibile sapere se il dispositivo è effettivamente smontato o meno
• Il filesystem "non montato" rimane accessibile in alcune circostanze
• Il filesystem "non montato" non è accessibile in alcune circostanze

C'è un falso senso di sicurezza : sembra che il filesystem sia stato smontato, ma in realtà è stato nascosto solo dallo spazio dei nomi / dall'erarchia.

• I processi possono ancora scrivere tramite descrittori di file aperti
• I file nuovi o esistenti possono essere aperti per la scrittura da processi con una directory di lavoro all'interno del mountpoint tramite relativi percorsi

Ciò significa che se non umount -l /media/hddsarai più in grado di accedere /media/hdd/dir/file(nome percorso assoluto) ma se hai un processo con directory di lavoro /media/hddsarà comunque in grado di creare nuovi processi in grado di leggere / scrivere ./dir/file(nome percorso relativo).

Se si tenta di smontare il dispositivo, verrà visualizzato un messaggio confuso:

# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted

Questo fa sembrare che il dispositivo sia stato smontato, ma possono esserci ancora dei processi che scrivono sul disco.

Dato che ci sono varie situazioni non ovvie che possono causare il blocco di umount , il filesystem potrebbe non essere smontato anche se lsof +f -- /dev/devicenon mostra nulla.

Non saprai mai se il filesystem effettivamente smonta. Non c'è modo di scoprirlo.

Dispositivi rimovibili

Se fai umount -lun disco rimovibile, sei in un limbo-land: non puoi essere sicuro che tutti i dati in sospeso siano stati scritti su disco.

Il meglio che puoi fare dopo una umount -lè assicurarti che tutta la scrittura sia completata e impedire la scrittura futura , ma non puoi ancora garantire che sia stata smontata.

Con i dispositivi rimovibili, se il dispositivo non è correttamente smontato, può verificarsi un comportamento strano alla successiva connessione:

• Il dispositivo otterrà un nome di dispositivo incrementato, ovvero /dev/sdbdiventa /dev/sdc. I messaggi di registro del kernel possono ancora fare riferimento /dev/sdbanche se quel dispositivo non esiste più come file sotto /dev. (L'unico modo che conosco per risolvere questo problema è riavviare.)

• la corruzione di btrfs può provocare. btrfs prevede che sia presente un solo filesystem con un determinato UUID alla volta. Il kernel vede ancora lo stesso UUID disponibile sul dispositivo fantasma e sul nuovo dispositivo. (Ho dovuto ricostruire il mio HDD di backup btrfs).

systemd trabocchetti

• Sembra che un pigro smonti o MNT_DETACHsia causato dall'uso x-systemd.mount-timeout=in /etc/fstabo dall'uso TimeoutIdleSec=in un file di montaggio automatico .

• Evitare soprattutto le systemdopzioni di cui sopra btrfs. Ho imparato dall'amara esperienza (vedi il riferimento btrfs sopra).