怠惰な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 を持つファイルシステムが一度に 1 つしか存在しないことを期待します。カーネルは、ファントムデバイスと新しいデバイスでまだ同じUUIDを見ることができます。 （btrfsバックアップハードドライブを再構築する必要がありました）。

systemd罠

• 怠惰な除去のように見えるMNT_DETACHx-systemd.mount-timeout=これは、ファイルを自動的にマウントするためにinを使用する/etc/fstabか、inを使用することによってTimeoutIdleSec=発生します。。

• 上記のsystemdオプション、特にbtrfs。私はこれを難しく学びました（上記のbtrfsを参照）。