web-dev-qa-db-ja.com

書き込み用に開いているファイルがある場合、 `mount -o remount、ro`は失敗することが保証されていますか?

リムーバブルデバイスを使用して、umount -lの安全で競合状態のない代替手段に取り組んでいます。

私が計画しているのは:

  1. umount --moveパーミッションディレクトリの下にある000なので、絶対パスでこれ以上ファイルを開くことはできません
  2. 書き込み用に開いているファイルを使用して、プロセスをインタラクティブに強制終了(または正常にシャットダウン)します
  3. 手順(2)が完了した場合にのみ、読み取り専用で原子的に再マウントします
  4. 問題を引き起こす可能性のある読み取り専用プロセスをインタラクティブに強制終了/閉じる
  5. 最後にumountを成功させる

ステップ(3)には、最後の対話型キルの後、mount -o remount,roの前に相対パスを持つファイルをrwで開くことができる競合状態があります。

書き込み用に開かれたファイルシステムにファイルがある場合、mount -o remount,roは失敗することが保証されていますか?

マニュアルページはこれについて沈黙しており、 デバイスはblockdev --setroの後でも書き込み可能 であることを知った後、私は少し妄想的です。

5
Tom Hale

はい。関連するコードは sb_prepare_remount_readonly (Linux 4.0以降、コードは他のバージョンでは異なる方法で編成される場合があります)。ロジックは次のとおりです。

  • マウントのインスタンスごとに:
    • そのインスタンスが読み取り専用でない場合:
      • 新しいライターが登録されないようにします(MNT_WRITE_HOLD)。
      • ライターが登録されている場合は、エラーフラグを設定します(EBUSYを返します)。
  • 削除された(iノード数= 0)がまだ削除されていない(ファイルが開いているためにまだ存在している)ファイルがある場合は、エラーフラグを設定します。
  • エラーフラグが設定されていない場合は、パーティションを読み取り専用としてマークします。
  • マウントのインスタンスごとに:
    • ライターの登録を禁止します。

登録されたライターは、書き込み用に開かれたファイルと、メタデータ(mkdirchmodなど)を書き込む進行中の操作です。 mnt_want_write これは登録されたライターの数が増加する場所です。

システムの設計により、読み取り専用の再マウントが書き込み登録バリアになることが保証されます。成功した場合、登録されたライターはありません。特に、再マウント操作時に書き込み用に開いているファイルはありません。再マウント後、書き込み用に開いているファイルはないため、書き込み用に開いているファイルはまだありません。