In article <bg5r4v$2pq$1@inb.m.ecl.ntt.co.jp>
ginga@athena.club.ne.jp writes:
>> ではなく、メタデータの指す先の実体とか、かなり細かく
>> 書込タイミングの制御をしているようです。
>原理的には上記の通りなんですが，
>HDD 内部(+ RAID その他)の write cache や，
>さらには SCSI の command queueing で問題は完全には解決されておらず，
>タイミングによっては災いは実際には起きる，
>ってことがあるんじゃないかと(あまり根拠なしに)思っているんですが，
>現実はどうなんでしょう?
実は私も懸念しています。最近は8MB cache内蔵とかいうdisk
も登場していますし。ただ、disk内部の状態とか、OSが知り得ない
部分まで面倒見れんよなあ、と諦めています。diskが「sync終了」
とか教えてくれたら良いんだけど。
あるいは中身を全て見せてくれて、*BSD側のcylinder block
の書込スケジュールを、diskのゾーン可変記録密度（用語は不正確
ですが、例の内周と外周でセクタ数が変わるやつ）に対応させる
とかやってみると面白そうなんだけど。

>> …ただ、VMやbuffer cacheの作りと密接に関係していて、5-current
>> ではVMのbugから、fsckで修復しきれなかったり、file buffer overcomitting
>> だっけ？そんなメッセージを吐いてpanic, rebootこいたりしていました。
>(5-current はまだ未体験なのですが)
>こちらは，soft updates というよりは UFS2 での改造とか
>そういうことではないのでしょうか?
UFS2での改造も当然関係している可能性大ですね。要するに効率や
パフォーマンス重視で、VM,buffer,cache,file system等を統合して
チューニングする余り、一部の変更があちこち、思わぬ所まで影響
してしまうと言う…。IT分野は、まだまだ革新的な技術が次から次
へと登場するので、簡単に変更・追随出来るようにした方が有利
ですね。*BSDはもう手遅れなので、やっぱりLinuxにはモノリシック
にせず、Micro kernelとまでいかずともOSkitの様にモジュールに
分けてモジュール単位で新技術の導入が出来るとかして欲しかった
なあと。今更ながらに、"Linux is obsolate"スレッドでのAST
教授の先見の明を思い知っています。
-- 
中村和志＠神戸         <mailto:kaz@kobe1995.net>
NAKAMURA Kazushi@KOBE   <http://kobe1995.jp/>
- Be Free(BSD), or Die...