Leniwy zdejmowania tworzy kot Schrödingera zamontować
- Nie możesz wiedzieć, czy urządzenie jest faktycznie odmontowane, czy nie
- System plików „odmontowany” pozostaje dostępny w niektórych okolicznościach
- System plików „odmontowany” jest w niektórych okolicznościach niedostępny
Istnieje fałszywe poczucie bezpieczeństwa : wygląda na to, że system plików został odmontowany, ale w rzeczywistości został ukryty tylko przed przestrzenią nazw / dziedziczeniem plików.
- Procesy mogą nadal zapisywać za pomocą otwartych deskryptorów plików
- Nowe lub istniejące pliki można otwierać do zapisu przez procesy z katalogiem roboczym wewnątrz punktu montowania za pomocą względnych nazw ścieżek
Oznacza to, że jeśli nie umount -l /media/hddbędziesz już mieć dostępu /media/hdd/dir/file(bezwzględna nazwa ścieżki), ale jeśli masz proces z katalogiem roboczym /media/hdd, nadal będzie mógł tworzyć nowe procesy, które mogą czytać / zapisywać ./dir/file(względna nazwa ścieżki).
Jeśli spróbujesz odmontować urządzenie, pojawi się mylący komunikat:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
To sprawia, że wygląda na to, że urządzenie nie zostało policzone, ale nadal mogą istnieć procesy zapisujące na dysk.
Ponieważ istnieją różne nieoczywiste sytuacje, które mogą powodować blokowanie umount , system plików może nadal nie zostać odmontowany, nawet jeśli lsof +f -- /dev/devicenic nie pokazuje.
Nigdy nie dowiesz się, czy system plików faktycznie odmontuje się. Nie ma sposobu, aby się dowiedzieć.
Urządzenie przenośne
Jeśli robisz umount -ldysk wymienny, jesteś w stanie zawieszenia: nie możesz być pewien, że wszystkie oczekujące dane zostały zapisane na dysku.
Najlepsze, co możesz zrobić po, umount -lto upewnić się, że wszystkie zapisy zostały zakończone i zapobiec pisaniu w przyszłości , ale nadal nie możesz zagwarantować, że zostało odmontowane.
W przypadku urządzeń wymiennych, jeśli urządzenie nie zostanie poprawnie odmontowane, może wystąpić dziwne zachowanie przy następnym podłączeniu:
Urządzenie otrzyma inkrementowaną nazwę urządzenia, tj . /dev/sdbStaje się /dev/sdc. Komunikaty dziennika jądra mogą nadal odnosić się do tego, /dev/sdbnawet jeśli to urządzenie już nie istnieje jako plik /dev. (Jedynym sposobem na rozwiązanie tego problemu jest ponowne uruchomienie.)
Może to spowodować uszkodzenie btrfs. btrfs oczekuje, że tylko jeden system plików o danym UUID jest obecny jednocześnie. Jądro nadal widzi ten sam UUID dostępny na urządzeniu fantomowym i nowym urządzeniu. (Musiałem odbudować mój twardy dysk zapasowy btrfs).
systemd gotchas
umount(2)Ostatnio czytałem kilka razy. Mówi tylko: „Wykonaj leniwy odmontowanie: uczyń punkt montowania niedostępnym dla nowych dostępów, natychmiast odłącz system plików i wszystkie systemy plików zamontowane pod nim od siebie i od tablicy montowania, i faktycznie wykonaj odmontowanie, gdy punkt montowania przestanie być zajęty . ” Ale niestety jest to mniej szczegółowe, nawet niż to, co podałeś.umount(8)mówi, że system plików jest zajęty „na przykład, gdy są w nim otwarte pliki lub gdy jakiś proces ma tam swój katalog roboczy lub gdy jest w nim używany plik wymiany”. To nie brzmi jak ostateczna lista, ale prawdopodobnie jest tak dobra, jak będę w stanie ją znaleźć.