Почему ленивый 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съемный диск, вы находитесь в подвешенном состоянии: вы не можете быть уверены, что все ожидающие данные были записаны на диск.

Лучшее, что вы можете сделать после a, umount -l- это обеспечить завершение всей записи и предотвратить ее дальнейшую запись , но вы все равно не можете гарантировать, что она была размонтирована.

На съемных устройствах, если устройство не отключено должным образом, может произойти странное поведение при следующем подключении:

• Устройство получит увеличенное имя устройства, т.е. /dev/sdbстанет /dev/sdc. Сообщения журнала ядра могут по-прежнему ссылаться, /dev/sdbдаже если это устройство больше не существует в виде файла /dev. (Единственный способ решить эту проблему - перезагрузить компьютер.)

• Btrfs коррупция может привести к. btrfs ожидает, что только одна файловая система с данным UUID присутствует одновременно. Ядро все еще видит тот же UUID, который доступен на фантомном устройстве и новом устройстве. (Я должен был восстановить мой резервный жесткий диск btrfs).

systemd подводные камни

• Кажется , что ленивым размонтирования или MNT_DETACHвызвано использованием либо x-systemd.mount-timeout=в /etc/fstabили с использованием TimeoutIdleSec=в файле монтирование .

• Избегайте вышеперечисленных systemdвариантов, особенно при использовании btrfs. Я учился на горьком опыте (см. Выше ссылку на btrfs).