[linux-users:61967] Re: IDEのWrite CacheがONに

[ichiro.takahashi _at_ xxxxxxxxxxxxx]

高橋 _at_ BSSです    ＊議論がかなり進んだ段階で遅まきながら異なった視点を



普通 UNIXの影響を受けた環境下でプログラム作る時って、ファイルライトに fprintf()とかの
高水準 I/O ライブラリと呼ばれる事もある stream I/O ライブラリを使いますよね？

プログラムＡが fprintf()を使ったとして

でこれがどこにデータを書くか？と言うと、これはプログラムＡにlibcからＡにリンクされた
ライブラリのバッファなんだよな。
   → アプリプログラム中ですでにキャッシングしている

ライブラリのバッファがオーバフローした時点で 高水準 stream関数は、
やっと（低水準と言われる）実際にＯＳコールを行う関数を呼び出す
	# ここまでは、libcのソースを読んだので確か

	# これ以降は、カーネルのソースを読んでいないので、推測
ＯＳコールでユーザ空間からカーネル空間にデータが渡され、
  （カーネル空間のどこにコーピーされるかと言うと知らないのですが、）
その後、仮想ファイルシステム、デバイスドライバ、主記憶上のディスクキャッシュ等を
たらい回しにした挙げ句
キャッシュフラッシュされる 30秒後（！まさかそんなに遅くはないか？）にやっと
ディスク装置に書き込みコマンドが発行される・・・

と、まあこんなシナリオでディスクの磁性体に書き出されると思っています

このシナリオだと、ライトキャッシュOFFにしておいても、エラーが発生するのは
ファイルライトを実行（したつもりにプログラムＡがなった時点）から30秒後にしか
ディスク装置はエラーを起こさないです


ここでUNIXの設計者が何を重点にシステム設計したかと*想像*するに
  システムの速度の向上
に見えます

では、信頼性の問題はどうするか？
  十分信頼性の高いハードウェアを使用する事
     → ワークステーションと呼ばれたシステムが、
        ぱそこんと呼ばれたシステムより１桁高価だったのはこれも大きな要因
  ソフト的には ダチョウアルゴリズムの適用で対処する

つまるところ、
  (ＯＳからユーザプログラムまでを含めた)システム全体のバランスをどう取るか？
を見渡さないで
ディスクデバイスに対するライトキャッシュ*だけ*がうんぬんって
とっても不毛な論議のような気がします



>
>あらき殿、伊藤です。
>
>ライト速度については、遅くなるというので間違いはありません。
>しかし、速度うんぬんよりも、ＵＮＩＸマシンという観点では信頼性重点が必要に
>思われます。
>
>期待しているユーザーは、安定した走行を望んでいるのでは・・・。
>
>基本的にリードキャッシュについてはＯＮでよいと思いますが、ライトキャッシュ
>については、ＯＦＦがデフォルトであるべきだと思っています。
>
>ＲＡＷモードについても勿論必要な機能であると思いますが、ブロック特殊におい
>ても、信頼性は絶対に必須項目であると思います。
>
>>あらきです。
>>HDD自体でのr/w cacheのはなしはLinuxの外のはなしなので、
>>
>>> > しかし、ライトキャッシュがＯＮになっていると、アプリがデータをライトした際、
>>> > キャッシュへのライトがＯＫならば、アプリに対し正常とかえってしまい、結果と
>>> > して、ディスクへのライト時エラーがでると、アプリはそれを検出することができ
>>> > ません。
>>> > これは、重要な問題になると思います。
>>>
>>> どのようなアプリかによると思うのですが、さきほども書いたように、
>>> そもそもカーネルがキャッシュをしているので、(キャッシュをoffにして)
>>> write(2)に成功したからといって、ハードウェアに反映されるとは限らない
>>> 気がしますが、私の勘違いでしょうか？
>>> それとも、fsync(2)してチェックするものなのでしょうか？
>>
>>fsyncしてしまえばあとはHDDコントローラの問題なので、そのHDDの設置状態などを
>>考慮して利用するのがいいのではないでしょうか。
>>たとえばUPSつけるとか、HDD電源boxを別にするとか。
>>
>>> > 本来は、性能が落ちてもライトキャッシュはオフにすべきだと思います。
>>> > どうでしょうか。
>>>
>>> バランスを考えると、「Linuxにrawデバイスを付けるべきだ」といった
>>> あたりの議論になるかと思います。その際にはじめてハードウェア
>>> キャッシュの有無が問題になるかと。(ちがうかな？)
>>
>>こっちの意見に賛成です。
>>パフォーマンスがまるで違ってきますから。
>>
>>あらき _at_ JLA
>>
>
>
>