web-dev-qa-db-ja.com

EXT4ファイルシステムがrelatimeとlazytimeの両方でマウントされるのはなぜですか

私はDebian 4.4をカーネル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

ただし、ファイルシステムはbothrelatimeおよびlazytimeでマウントされているようです。

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

どうすればいいの？

ext4atime
5
andreas-h

朗報です。予想通りです。

Lazytimeフラグは、strictatime/relatime/noatimeから独立しています。デフォルトはrelatimeです。したがって、noatimeをlazytimeに置き換えたときに、relatimeマウントオプションが設定されているのを目にしても驚くことではありません。

- Ted Ts'o

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

マンページを文字どおり読むと、relatimeがメモリ内更新とディスク書き込みの両方を抑制することが示唆されています。 lazytimeは、ディスクへの書き込みのみを抑制します（atimeだけでなくmtimeにも適用されます）。 lazytimeの実装につながった議論を考えると、これは私には理にかなっています。 IOW relatimeのテストを書くのはとても簡単でしょう。ただし、ディスクの書き込みを確認するか、クリーンでないシャットダウンで何が起こるかをテストすると、lazytimeの影響はonlyになります。

個人的には、mtimeに対するレイジータイムの影響は少し奇妙に聞こえます。たぶん、それは稼働時間の長いシステムに最適な最適化かもしれませんが、平均的なデスクトップについてはわかりません...そして最近では、それは実際にはラップトップです。 powerfailでの未定義または奇妙に部分的に定義された動作については、それほど大げさなことになっているわけではありません。 btrfsのようなコピーオンライトファイルシステムを考えると、さらに特殊なケースになります。 「iノード」は、ファイルサイズが変更されない場合でも更新される可能性があります。対照的に、relatimeは美しく、確定的です。

また、mtimeの最適化は、サイズを変更しない多数のファイルへの書き込みがある場合にのみ役立つようです。そのための一般的なベンチマークがあるかどうかはわかりません。非常に重要なデータベースワークロードがいくつかあると思います。

真剣にテッド、なぜlazyatimeが手に入らなかったの？

6
sourcejedi