Tại sao lười biếng MNT_DETACH hoặc `umount -l` không an toàn / nguy hiểm?

Tôi đã đọc ở một vài nơi umount -lkhông an toàn:

Trong câu trả lời của @cas :

không sử dụng umount's --lazytùy chọn nếu bạn quan tâm khi ổ đĩa ngoài có thể được an toàn unplugged

Một bình luận của @frostschutz :

umount --lazykhông an toàn và không thể được thực hiện an toàn. [...]

util-linux Nhận xét này của Ruediger Meier :

Bạn nên tránh sử dụng umount -ltất cả. Chỉ cần giết tất cả các quy trình đang sử dụng /tmp/mountpointvà sau đó không có tùy chọn -l.

Tại sao umount -lkhông an toàn / nguy hiểm?

Có cách nào để làm cho nó an toàn?

Một unmount lười biếng tạo ra một gắn kết mèo Schrödinger

• Bạn không thể biết thiết bị có thực sự chưa được kết nối hay không
• Hệ thống tập tin "chưa từng có" vẫn có thể truy cập được trong một số trường hợp
• Không thể truy cập hệ thống tập tin "không đếm được" trong một số trường hợp

Có một cảm giác an toàn sai lầm : có vẻ như hệ thống tập tin đã bị bỏ qua, nhưng trong thực tế, nó chỉ bị ẩn khỏi không gian tên tập tin / gia truyền.

• Các quy trình vẫn có thể viết thông qua các mô tả tệp mở
• Các tệp mới hoặc hiện có có thể được mở để ghi bằng các quy trình có thư mục hoạt động bên trong điểm gắn kết thông qua tên đường dẫn tương đối

Điều này có nghĩa là nếu bạn umount -l /media/hddkhông còn có thể truy cập /media/hdd/dir/file(tên đường dẫn tuyệt đối) nhưng nếu bạn có một quy trình với thư mục làm việc, /media/hddnó vẫn có thể tạo các quy trình mới có thể đọc / ghi ./dir/file(tên đường dẫn tương đối).

Nếu bạn cố gắng ngắt kết nối thiết bị, bạn sẽ thấy một thông báo khó hiểu:

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

Điều này làm cho nó trông giống như thiết bị đã được đếm, nhưng vẫn có thể có các quá trình ghi vào đĩa.

Vì có nhiều tình huống không rõ ràng khác nhau có thể gây ra tình trạng chặn , hệ thống tập tin vẫn có thể không được khắc phục mặc dù lsof +f -- /dev/devicekhông hiển thị gì.

Bạn sẽ không bao giờ biết nếu hệ thống tập tin thực sự ngắt kết nối. Không có cách nào để tìm hiểu.

Thiết bị di động

Nếu bạn làm umount -lmột đĩa di động, bạn đang ở trong vùng đất lấp lửng: bạn không thể chắc chắn rằng tất cả dữ liệu đang chờ xử lý đã được ghi vào đĩa.

Điều tốt nhất bạn có thể làm sau một umount -llà đảm bảo tất cả các văn bản hoàn thành và ngăn chặn việc viết trong tương lai , nhưng bạn vẫn không thể đảm bảo rằng nó đã được bỏ qua.

Với các thiết bị di động, nếu thiết bị không được kết nối đúng cách, hành vi lạ có thể dẫn đến lần cắm tiếp theo:

• Thiết bị sẽ nhận được một tên thiết bị tăng, tức là /dev/sdbtrở thành /dev/sdc. Các thông điệp nhật ký kernel vẫn có thể tham chiếu /dev/sdbngay cả khi thiết bị đó không còn tồn tại dưới dạng tệp /dev. (Cách duy nhất tôi biết để giải quyết vấn đề này là khởi động lại.)

• tham nhũng btrfs có thể dẫn đến. btrfs hy vọng rằng chỉ có một hệ thống tập tin với một UUID nhất định có mặt tại một thời điểm. Nhân vẫn thấy UUID tương tự có sẵn trên thiết bị ảo và thiết bị mới. (Tôi đã phải xây dựng lại ổ cứng sao lưu btrfs của mình).

systemd vấn đề

• Có vẻ như lười biếng unmount hoặc MNT_DETACHđược gây ra bằng cách sử dụng x-systemd.mount-timeout=trong /etc/fstabhoặc sử dụng TimeoutIdleSec=trong một tệp Automount .

• Tránh các systemdtùy chọn trên đặc biệt là sử dụng btrfs. Tôi học được từ kinh nghiệm cay đắng (xem tài liệu tham khảo btrfs ở trên).