Uma desmontagem lenta cria um gato de Schrödinger montado
- Você não pode saber se o dispositivo está realmente desmontado ou não
- O sistema de arquivos "desmontado" permanece acessível em algumas circunstâncias
- O sistema de arquivos "desmontado" não está acessível em algumas circunstâncias
Existe uma falsa sensação de segurança : parece que o sistema de arquivos foi desmontado, mas na realidade ele só foi escondido do namespace / hierarquia do arquivo.
- Os processos ainda podem ser escritos por meio de descritores de arquivos abertos
- Arquivos novos ou existentes podem ser abertos para gravação por processos com um diretório de trabalho dentro do ponto de montagem por meio de caminhos relativos
Isso significa que se você umount -l /media/hdd
não poderá mais acessar /media/hdd/dir/file
(nome de caminho absoluto), mas se você tiver um processo com o diretório de trabalho /media/hdd
, ele poderá criar novos processos que podem ler / write ./dir/file
(caminho relativo).
Se você tentar desmontar o dispositivo, verá uma mensagem confusa:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
Isso faz com que pareça que o dispositivo foi desconectado, mas ainda ainda pode ser processos gravados no disco.
Como existem várias situações não óbvias que podem causar o seu bloqueio , o sistema de arquivos ainda pode não ser desmontado mesmo que lsof +f -- /dev/device
não mostre nada.
Você nunca saberá se o sistema de arquivos é realmente desmontado. Não há como descobrir.
Dispositivos removíveis
Se você usa umount -l
de um disco removível, você está no limbo: não pode ter certeza de que todos os dados pendentes foram gravados no disco.
O melhor que você pode fazer depois de um umount -l
é garantir que toda a redação seja concluída e impedir futuras redações , mas você ainda não pode garantir que tenha sido desmontado.
Com dispositivos removíveis, se o dispositivo não for devidamente desmontado, pode ocorrer um comportamento estranho na próxima vez que ele for conectado:
-
O dispositivo receberá um nome de dispositivo incrementado, ou seja,
/dev/sdb
se tornará/dev/sdc
. As mensagens de log do kernel ainda podem se referir a/dev/sdb
, mesmo que esse dispositivo não exista mais como um arquivo em/dev
. (A única maneira que eu sei para resolver isso é reiniciar.)- corrupção 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)