Por que MNT_DETACH preguiçoso ou `umount -l` não é seguro / perigoso?

Eu li em alguns lugares que umount -lnão é seguro:

Em uma resposta de @cas :

não use umounta --lazyopção se você se preocupa com quando a unidade externa pode ser desconectada com segurança

Um comentário de @frostschutz :

umount --lazynão é seguro e não pode ser tornado seguro. [...]

Este util-linux comentário de Ruediger Meier :

Você deve evitar o uso umount -l. Apenas mate todos os processos que estão usando /tmp/mountpointe depois desmonte sem opção -l.

Por que é umount -linseguro / perigoso?

Existe uma maneira de torná-lo seguro?

Uma desmontagem preguiçosa cria uma montaria de gato de Schrödinger

• Você não pode saber se o dispositivo está realmente desmontado ou não
• O sistema de arquivos "não montado" permanece acessível em algumas circunstâncias
• O sistema de arquivos "desmontado" não é acessível em algumas circunstâncias

Há uma falsa sensação de segurança : parece que o sistema de arquivos foi desmontado, mas, na realidade, só foi oculto no espaço para nome / hierarquia do arquivo.

• Os processos ainda podem gravar via descritores de arquivo aberto
• Arquivos novos ou existentes podem ser abertos para gravação por processos com um diretório ativo dentro do ponto de montagem através de nomes de caminho relativos

Isso significa que se você umount -l /media/hddnão conseguir mais acessar /media/hdd/dir/file(nome do caminho absoluto), mas se tiver um processo com diretório /media/hddativo, ainda poderá criar novos processos que podem ler / gravar ./dir/file(nome do caminho relativo).

Se você tentar desmontar o dispositivo, receberá uma mensagem confusa:

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

Isso faz parecer que o dispositivo não foi montado, mas ainda pode haver processos gravando no disco.

Como existem várias situações não óbvias que podem causar o bloqueio de umount , o sistema de arquivos ainda não pode ser desmontado, embora lsof +f -- /dev/devicenão mostre nada.

Você nunca saberá se o sistema de arquivos realmente desmonta. Não há como descobrir.

Dispositivos removíveis

Se você cria umount -lum disco removível, está no limbo-land: não pode ter certeza de que todos os dados pendentes foram gravados no disco.

O melhor que você pode fazer após a umount -lé garantir que todas as gravações sejam concluídas e impedir futuras gravações , mas você ainda não pode garantir que elas foram desmontadas.

Com dispositivos removíveis, se o dispositivo não estiver adequadamente desmontado, poderá ocorrer um comportamento estranho na próxima vez em que for conectado:

• O dispositivo receberá um nome de dispositivo incrementado, ou seja, /dev/sdbse tornará /dev/sdc. As mensagens de log do kernel ainda podem se referir /dev/sdb, embora esse dispositivo não exista mais como um arquivo em /dev. (A única maneira que sei resolver isso é reiniciar.)

• A corrupção do btrfs pode resultar. O btrfs espera que apenas um sistema de arquivos com um determinado UUID esteja presente ao mesmo tempo. O kernel ainda vê o mesmo UUID disponível no dispositivo fantasma e no novo dispositivo. (Eu tive que reconstruir meu disco rígido de backup btrfs).

systemd Pegadinhas

• Parece que uma desmontagem preguiçoso ou MNT_DETACHé causado por usando x-systemd.mount-timeout=em /etc/fstabou usar TimeoutIdleSec=em um arquivo Automount .

• Evite as systemdopções acima , especialmente, está usando btrfs. Eu aprendi com uma experiência amarga (consulte a referência do btrfs acima).