Чому лінивий MNT_DETACH або `umount -l` небезпечний / небезпечний?

Я читав у кількох місцях, що не umount -lє безпечним:

У відповіді @cas :

не використовуйте umount«s --lazyваріант , якщо ви дбаєте про те, коли зовнішній накопичувач може бути безпечно відключений

Коментар @frostschutz :

umount --lazyне є безпечним і не може бути безпечним. [...]

Цей util-linux коментар Ruediger Meier :

Слід уникати використання umount -lвзагалі. Просто вбийте всі процеси, які використовуєте, /tmp/mountpointа потім виправдайте без варіанту -l.

Чому 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 gotchas

• Здається, що ледачий відключення або MNT_DETACHспричинений використанням або x-systemd.mount-timeout=в файлі Automount, /etc/fstabабо TimeoutIdleSec=в ньому .

• Уникайте перерахованих вище systemdваріантів, особливо це стосується використання btrfs. Я дізнався з гіркого досвіду (див. Посилання на btrfs вище).