게으른 MNT_DETACH 또는 `umount -l`이 안전하지 않거나 위험한 이유는 무엇입니까?

지연 제거로 인해슈뢰딩거의 고양이산

• 장치가 실제로 제거되었는지 알 수 있는 방법이 없습니다.
• "마운트 해제된" 파일 시스템유적특정 상황에서 접근 가능
• "마운트 해제된" 파일 시스템아니요특정 상황에서 접근 가능

하나 있다잘못된 안전감: 파일 시스템이 마운트 해제된 것처럼 보이지만 실제로는 파일 네임스페이스/계층에서 숨겨져 있을 뿐입니다.

• 프로세스는 열린 파일 설명자를 통해 계속 쓸 수 있습니다.
• 상대 경로 이름을 사용하여 마운트 지점 내의 작업 디렉터리가 있는 프로세스에서 쓰기 위해 새 파일이나 기존 파일을 열 수 있습니다.

이는 umount -l /media/hdd더 이상 (절대 경로 이름)에 액세스할 수 없지만 /media/hdd/dir/file작업 디렉터리가 있는 프로세스가 있는 경우 읽기/쓰기가 가능한 새 프로세스(상대 경로 이름)를 /media/hdd계속 생성할 수 있음을 의미합니다../dir/file

장치를 제거하려고 하면 다음과 같은 혼란스러운 메시지가 표시됩니다.

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

이로 인해 장치가 계산되지 않은 것처럼 보이지만아직디스크에 쓰는 프로세스일 수 있습니다.

다양하게 있기 때문에umount가 차단될 수 있는 불분명한 상황, 아무것도 표시되지 않더라도 lsof +f -- /dev/device파일 시스템이 여전히 마운트 해제되지 않을 수 있습니다.

파일 시스템이 실제로 마운트 해제되었는지는 알 수 없습니다. 알 방법이 없습니다.

이동식 장비

이동식 디스크를 사용하여 이 작업을 수행하면 umount -l문제가 발생합니다. 보류 중인 모든 데이터가 디스크에 기록되었는지 확인할 수 없습니다.

나중에 할 수 있는 가장 좋은 umount -l일은모든 쓰기가 완료되었는지 확인하고 향후 쓰기를 방지합니다., 하지만 여전히 제거되었다는 보장은 없습니다.

이동식 장치의 경우 장치가 제대로 마운트 해제되지 않으면 다음에 연결할 때 이상한 동작이 발생할 수 있습니다.

• 장치는 가 /dev/sdb되는 증분된 장치 이름을 갖게 됩니다 /dev/sdc. /dev/sdb장치가 더 이상 작동 하지 않더라도 /dev(이 문제를 해결하는 유일한 방법은 재부팅하는 것입니다.)

• btrfs 손상이 발생할 수 있습니다. btrfs는 주어진 UUID를 가진 파일 시스템이 한 번에 하나만 존재할 것으로 예상합니다. 커널은 팬텀 장치와 새 장치에서 여전히 동일한 UUID를 볼 수 있습니다. (btrfs 백업 하드 드라이브를 다시 구축해야 했습니다).

systemd덫

• 게으른 제거처럼 보이거나MNT_DETACHx-systemd.mount-timeout=이는 파일을 자동으로 마운트하기 위해 in을 사용 /etc/fstab하거나 in을 사용 함으로써 TimeoutIdleSec=발생합니다 ..

• 위 systemd옵션, 특히 btrfs. 나는 이것을 어렵게 배웠습니다(위의 btrfs 참조 참조).