web-dev-qa-db-ja.com

LinuxがFATをマウントしただけで「ダーティ」とマークするのはなぜですか?

USBメモリスティック(FATフォーマット)をWindows PCに挿入し、「イジェクト」せずにプラグを抜いてから再度挿入すると、Windowsは「問題がある可能性がある」という警告を出さずに問題ありません。

しかし、Linux(Ubuntu 15.04など)で同じことを行うと、2回目に挿入した後、次のような警告メッセージがログに表示されます。

FAT-fs (sdf1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

その後、Windows PCに配置すると、エラーをチェックするように求めるメッセージがポップアップ表示されます。

LinuxがFATの「ダーティ」フラグを処理するのはなぜそれほど基本的なのですか?本当に「ダーティ」である可能性がある場合にのみ「ダーティ」フラグを設定する方がよいと思いました。何かのようなもの:

  • ファイルの書き込み時に「ダーティ」フラグを設定します。
  • 次の場合に「ダーティ」フラグをクリアします:
    • 書き込まれたファイルがすべて閉じられている、および/または
    • 書き込みキャッシュはディスクに書き出され、
    • そしてもちろん、ディスクがアンマウントされたとき。

実際には何も書かれていなくても、リムーバブルデバイスを接続したり取り外したりするだけでユーザーが「ダーティ」フラグの誤警報を受け取る可能性を減らすために、そのモードで動作するマウントオプションが少なくともいくつかあると便利です。

3
Craig McQueen

私のCはラフですが、 スーパーブロックの読み取り時にファットダーティビットが設定されます (この commit がなぜ実装されたのかを説明しています)のように見えます。

Windowsは、FSで何かが変更されるまで、ビットを設定しないことを選択する場合があります。ここで、Linuxは、マウント時にビットを設定するというもう少し偏執的なアプローチを取ります。

私には、マウント後にダーティを想定し、クリーンアンマウント時にアンセットする方が効率的であるように思われます。そうしないと、カーネルはボリュームのダーティ/クリーン状態を追跡し、書き込みごとに設定する必要があるかどうかを確認する必要があります。

コードとコミットコメントでわかるように、 ROをマウントでき、ビットは変更されません。

7
Nathan V