EXT4ファイルシステムがrelatimeとlazytimeを同時にマウントするのはなぜですか?

EXT4ファイルシステムがrelatimeとlazytimeを同時にマウントするのはなぜですか?

私はDebian / Testing、カーネル4.4を実行しています:

# uname -a
Linux shaula 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux

だから私はマウントオプションを使いたかったので、以下lazytimeを私のオプションに入れました/etc/fstab

# grep vg_crypt-root /etc/fstab 
/dev/mapper/vg_crypt-root   /   ext4   lazytime,errors=remount-ro   0   1

ただし、ファイルシステムは次のようになります。両方 relatimeそしてlazytime

# grep vg_crypt-root /etc/mtab 
/dev/mapper/vg_crypt-root / ext4 rw,lazytime,relatime,errors=remount-ro,data=ordered 0 0

どうやって?

ベストアンサー1

良いニュース:これは予想されるものです。

Lazytime フラグは strictatime/relatime/noatime とは無関係です。デフォルトは相対時間です。したがって、noatimeをlazytimeに置き換えるときにrelatimeマウントオプションを設定することは驚くべきことではありません。

-テッド・ジョー

残念ながら、これはそれが何を意味するのか説明しません。

マンページをそのまま読んでみると相対性抑制があることがわかります。両方メモリ更新とディスク書き込み。 Lazytimeはディスク書き込みのみを抑制します(そしてmtimeとatimeで動作します)。遅延時間の実装につながる議論を考えると、これは私にとって意味があります。 IOW、関係テストの作成は非常に簡単です。しかし、怠惰な時間の効果は次のとおりです。ただディスクへの書き込みを見たり、異常終了によって何が起こったかをテストしたりすると、これを確認できます。


個人的には、mtimeに対する遅延時間の影響は少し奇妙に聞こえます。おそらく、これはより高い稼働時間のシステムのための良い最適化かもしれませんが、一般的なデスクトップではどうかわかりません。または、あまりにも情熱的に欠陥があるときに部分的に定義された奇妙な行動。 btrfsなどの書き込み中にコピーファイルシステムを考慮すると、ファイルサイズが大きくなっても「inode」が更新される可能性があることを考慮すると、状況はさらに特別になります。いいえ変化。比較するとrelatime愛らしくて確実です。

そして、mtimeの最適化は、多くのファイルを書き込んでファイルサイズが変わらない場合にのみ便利です。共通のベンチマークがあるかどうかわかりません。私はこれが非常に重要なデータベースワークロードだと思います。

本当に、テッド、なぜ私はそれを見つけることができなかったのですかlazyatime

おすすめ記事