Linux での遅延アンマウントまたはビジーディスクのアンマウント

Linux での遅延アンマウントまたはビジーディスクのアンマウント

'lazy' オプションを使用すると、使用中のディスクを 'umount' できると読んだことがあります。man ページには、これについて次のように書かれています。

umount - ファイルシステムをアンマウントする

-l 遅延アンマウント。ファイルシステムをファイルシステム階層から切り離し、ビジー状態でなくなったらすぐにファイルシステムへのすべての参照をクリーンアップします。このオプションを使用すると、「ビジー」状態のファイルシステムをアンマウントできます。(カーネル 2.4.11 以降が必要です。)

しかし、それでは一体何の意味があるのでしょうか? そもそもパーティションをアンマウントする理由について考えてみました。

  1. ハードウェアを取り外すには
  2. マウント中に実行するのは安全ではないファイルシステムの操作を実行する

どちらの場合でも、「怠惰な」アンマウントが果たす役割は、ディスクが本当にアンマウントされているかどうか、そして実際にこれらのアクションを続行できるかどうかの判断を困難にすることだけだと、私は考えています。唯一の用途は、umount -l経験の浅いユーザーが、実際には達成していないことを達成したように「感じる」ことであるように思われます。

なぜ遅延アンマウントを使用するのでしょうか?

答え1

たとえば、Web サーバーなどのソフトウェアがログを書き込むボリュームを変更する必要があるが、トラフィック量が多く、操作中にボリュームをオフにすることも、ログ パスを変更することもできないとします。

遅延アンマウントを使用すると、ソフトウェアの実行中にボリュームを安全にアンマウントし、同じマウントポイントに別のボリュームをマウントして、ソフトウェアにファイルを再度開くように指示することができます。

理想的には、ソフトウェアをオフにする必要がないため、リクエストは失われず、ファイルが再度開かれるまで古いマウントに書き込まれていたため、ログ エントリも基本的に失われません (ソフトウェアがファイルの再度のオープンをどの程度うまく処理するかはソフトウェア次第です)。

マニュアルページを言い換えると、遅延アンマウント時にボリュームに開いているファイルがある場合、実際にはボリュームはマウントされたままですが、ファイルシステムからアクセスできないだけで、最後の開いているファイルが閉じられたときにのみ実際にアンマウントされることを意味します。

答え2

怠け者なので、ディスク操作が完了したらアンマウントしたいのです。

考えられるシナリオは次の通りです。

rsyncバックアップを実行して立ち去るために使用しています。umount -lドライブを取り外し、コピーと同期が完了するとマウントが解除されるため、休憩後 (バックアップよりも時間がかかることが分かっている場合) に戻ってきたときに、キーボードを再度操作する必要はなく、ドライブを取り外すだけで済みます。

答え3

これは実際には、管理タスクにおけるフォローアップタスクを実行するための時間を増やすために実装されています。

このタスクとは無関係に、パイプライン内でさらにタスクが待機している場合は、遅延アンマウントしてバッチ内の他のタスクを続行できます。

: タスク 1 とタスク 2 は、連続してスケジュールされた 2 つの管理タスクです。

タスク1毎日のバックアップ

これは、プロジェクト パーティションからバックアップ パーティション (/mnt/backupProj など) に大量のファイルをコピーします。バックアップ パーティションはオンザフライでマウントされ、このタスクの終了時にアンマウントされます。コピーにはかなりの時間がかかります。

タスク 2SQLビューの更新

専用サーバー上で一連のデータベース ビュー更新を実行します。

タスク 2 は明らかにタスク 1 から完全に独立しているため、バックアップ タスクが完了するのを待たずに /mnt/backupProj を遅延アンマウントできます。

答え4

次のような作業を行うときに見られるバインド マウントについて考えてみましょうchroot

mount --rbind /proc /mnt/proc
# do stuff
umount /mnt/proc

システム上に絶えず問い合わせを行うデーモンがある場合/proc(つまり、あなたですksysguardd)、 は実行できません。この場合、umount /mnt/procLazy を使用すると実行できます。umount

関連情報