大阪大学の齊藤です

Yasushi Shinjo wrote:

> 新城＠筑波大学情報です。こんにちは。
> write back という用語がよく分からないのですが、これは、write 
> しても、ディスク側のキャッシュに書くだけで、実際にはディスク
> には書かれないという意味ですか。
> 
> 共有メモリの一貫性なら、write-through/copy-back というのはい
> いんだけど。ハードディスクなら、書き手は１つだから、back は
> ないんじゃないかと。

ディスクブロックの部分書き換えということもありますから、
(read-modify-write)べつに良いんじゃないでしょうか。日本語でも
「書き戻す」と言いますし。

とくにUNIXでは、ファイルシステムドライバは、あくまでも
バッファキャッシュやinodeキャッシュのみを相手にして
更新し、それをディスクに書き戻すのはファイルシステム
モジュールではなくて、バッファキャッシュモジュールや
inodeキャッシュモジュールの仕事(ふぁいるシステムモジュール
からはディスクI/Oはみえない)という構造になっているので、
ちょっと感覚が他のOSとは違うかも。

> aggregate の所がよくわからないんだけど、

> いくら溜めても、メモリが無くなれば最後は write するしかいな
> ので、平均的には特かもしれないけれど、極限状態だと危ないこと
> もあるんじゃないかなあ。

inodeやディレクトリなどは、1つのディスクブロックに複数の
エントリが含まれるので、複数の更新要求をバッファキャッシュ
で１回のディスクブロック更新にまとめることが出来ます。
積極的にこれをやるかどうかは性能に大きく影響を与えます。

また、一般にHDDは、ある程度の大きさの読み書きでないと性能が
出ません。4KBを16回書き込むよりは64KBを一気に書き込む方が
格段に早い。実際FFSでは、ファイルの内容(のある程度の大きさの
かたまり)をディスクの連続領域に割り当てるようにします。

キャッシュに溜める時間をむやみに延ばしても性能は頭打ちで
危険度は時間比例で高まるので、適切な時間待って書き込む
(dirtyblockを長時間持たない)のがバッファキャッシュの
チューニングのミソ。

たとえば、NEWS　OSの非同期書き込みの初期には、
長く溜めすぎて、「しばらく高速に動くんだけど
バッファキャッシュを使い切ったところでHDDランプが
点灯しっぱなしになって30秒くらいがくっと体感性能が
落ちる」なんて不具合が出たりしていました。
結局、全dirty blockを一気にscheduleするというsyncの
仕組みを捨ててやっとまともになりましたっけ。

        齊藤明紀　saitoh@ist.osaka-u.ac.jp