[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[linux-users:61969] Re: IDEのWrite CacheがONになっているのは問題ではないか


高橋殿、伊藤です。

詳しい解説ありがとうございます。
確かに、ストリームへ処理を依頼してから、ディスクに書かれるまでの時間というのには
いろいろ処理がありますね。
#一点にとらわれると、他の同類問題が目に見えなくなりますね。

LinuxおよびFreeBSD開発者は、やはり性能よりもパフォーマンスを意識していることが良
くわかります。

アプリケーションとしては、syncやfflushなどでバッファを吐き出した後、再度書き込み
データの内容の比較を行うという処理を追加するといったことをすればいいですね。

システムが最高のパフォーマンスで応えるのでしたら、アプリケーションで信頼を追及す
るなんてのもいいかもしれませんね。

>高橋 _at_ BSSです    *議論がかなり進んだ段階で遅まきながら異なった視点を
>
>普通 UNIXの影響を受けた環境下でプログラム作る時って、ファイルライトに fprintf()とかの
>高水準 I/O ライブラリと呼ばれる事もある stream I/O ライブラリを使いますよね?
>
>プログラムAが fprintf()を使ったとして
>
>でこれがどこにデータを書くか?と言うと、これはプログラムAにlibcからAにリンクされた
>ライブラリのバッファなんだよな。
>   → アプリプログラム中ですでにキャッシングしている
>
>ライブラリのバッファがオーバフローした時点で 高水準 stream関数は、
>やっと(低水準と言われる)実際にOSコールを行う関数を呼び出す
>	# ここまでは、libcのソースを読んだので確か
>
>	# これ以降は、カーネルのソースを読んでいないので、推測
>OSコールでユーザ空間からカーネル空間にデータが渡され、
>  (カーネル空間のどこにコーピーされるかと言うと知らないのですが、)
>その後、仮想ファイルシステム、デバイスドライバ、主記憶上のディスクキャッシュ等を
>たらい回しにした挙げ句
>キャッシュフラッシュされる 30秒後(!まさかそんなに遅くはないか?)にやっと
>ディスク装置に書き込みコマンドが発行される・・・
>
>と、まあこんなシナリオでディスクの磁性体に書き出されると思っています
>
>このシナリオだと、ライトキャッシュOFFにしておいても、エラーが発生するのは
>ファイルライトを実行(したつもりにプログラムAがなった時点)から30秒後にしか
>ディスク装置はエラーを起こさないです
>
>
>ここでUNIXの設計者が何を重点にシステム設計したかと*想像*するに
>  システムの速度の向上
>に見えます
>
>では、信頼性の問題はどうするか?
>  十分信頼性の高いハードウェアを使用する事
>     → ワークステーションと呼ばれたシステムが、
>        ぱそこんと呼ばれたシステムより1桁高価だったのはこれも大きな要因
>  ソフト的には ダチョウアルゴリズムの適用で対処する
>
>つまるところ、
>  (OSからユーザプログラムまでを含めた)システム全体のバランスをどう取るか?
>を見渡さないで
>ディスクデバイスに対するライトキャッシュ*だけ*がうんぬんって
>とっても不毛な論議のような気がします
>
>>
>>あらき殿、伊藤です。
>>
>>ライト速度については、遅くなるというので間違いはありません。
>>しかし、速度うんぬんよりも、UNIXマシンという観点では信頼性重点が必要に
>>思われます。
>>
>>期待しているユーザーは、安定した走行を望んでいるのでは・・・。
>>
>>基本的にリードキャッシュについてはONでよいと思いますが、ライトキャッシュ
>>については、OFFがデフォルトであるべきだと思っています。
>>
>>RAWモードについても勿論必要な機能であると思いますが、ブロック特殊におい
>>ても、信頼性は絶対に必須項目であると思います。
>>
>>>あらきです。
>>>HDD自体でのr/w cacheのはなしはLinuxの外のはなしなので、
>>>
>>>> > しかし、ライトキャッシュがONになっていると、アプリがデータをライトした際、
>>>> > キャッシュへのライトがOKならば、アプリに対し正常とかえってしまい、結果と
>>>> > して、ディスクへのライト時エラーがでると、アプリはそれを検出することができ
>>>> > ません。
>>>> > これは、重要な問題になると思います。
>>>>
>>>> どのようなアプリかによると思うのですが、さきほども書いたように、
>>>> そもそもカーネルがキャッシュをしているので、(キャッシュをoffにして)
>>>> write(2)に成功したからといって、ハードウェアに反映されるとは限らない
>>>> 気がしますが、私の勘違いでしょうか?
>>>> それとも、fsync(2)してチェックするものなのでしょうか?
>>>
>>>fsyncしてしまえばあとはHDDコントローラの問題なので、そのHDDの設置状態などを
>>>考慮して利用するのがいいのではないでしょうか。
>>>たとえばUPSつけるとか、HDD電源boxを別にするとか。
>>>
>>>> > 本来は、性能が落ちてもライトキャッシュはオフにすべきだと思います。
>>>> > どうでしょうか。
>>>>
>>>> バランスを考えると、「Linuxにrawデバイスを付けるべきだ」といった
>>>> あたりの議論になるかと思います。その際にはじめてハードウェア
>>>> キャッシュの有無が問題になるかと。(ちがうかな?)
>>>
>>>こっちの意見に賛成です。
>>>パフォーマンスがまるで違ってきますから。
>>>
>>>あらき _at_ JLA
>>>
>>
>>
>>
>
>

この情報があなたの探していたものかどうか選択してください。
yes/まさにこれだ!   no/違うなぁ   part/一部見つかった   try/これで試してみる

あなたが探していた情報はどのようなことか、ご自由に記入下さい。特に「まさにこれだ!」と言う場合は記入をお願いします。
例:「複数のマシンからCATV経由でipmasqueradeを利用してWebを参照したい場合の設定について」
References: