[b-free 508] Re: それは機械が壊れている

Ryuichi Naitoh (naitoh_r@soft.hitachi.co.jp)
Thu, 11 Sep 1997 17:27:09 +0900

隆一です。

From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
Subject: [b-free 506] Re: それは機械が壊れている
Date: Thu, 11 Sep 1997 14:57:57 +0900

> 林です。
>
> In message <199709110424.NAA18986@hisoft.soft.hitachi.co.jp>
> "[b-free 505] Re: それは機械が壊れている"
> "Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>" wrote:
> naitoh_r> うーん、論理ブロックのバイト数と物理媒体のブロックのバイト数とは、
> naitoh_r> 対応していなくてもいいと思う方に一票 ^^;。
> naitoh_r>
> naitoh_r> しかし、考えてみるとチェック情報とデータとは分けてしまった方がいいかも
> naitoh_r> しれません。データ破壊が局所的でなく大域的にまとめて起こるならば、デー
> naitoh_r> タ破壊と一緒にチェック情報も壊れてしまう可能性が大です。そうすると、
> naitoh_r> チェック情報はデータとは別にファイル管理情報と共に入れておく方が安全な
> naitoh_r> 気もします。大域的にデータ破壊が起きるとデータ訂正は難しそうですが、
> naitoh_r> どのくらい破壊されたかは分かるだけでも助かりますから。
> naitoh_r>
> naitoh_r> ところで、BTRON ファイルシステムの API の仕様では、論理単位の大きさを
> naitoh_r> 意識しているところというのは、どういうところでしょうか?
> naitoh_r> 論理単位を意識するような API は、いっそのこと変更してしまった方がいい
> naitoh_r> ように思います。
>
> レコードサイズの拡大時に連続ブロックを取得する機能があります。
> この連続カウントをKB単位で指定するはずです。基本的にはITRON/FILE
> の機能でBTRONでは0(無指定)にするように指示されていたはずです。
> 基本的にリアルタイム対応の機能ですからBTRONでは無くても良いです。
> でも実装するなら物理的なブロック単位とずれるのは問題です。意図の
> 通りの性能を出せないということになりますから。

えーと、論理ブロックのアクセスの単位が物理的なブロック単位とずれたとし
ても、性能は劣化しないような気がしますが、どうでしょうか?

最終的にファイルシステムが物理ブロック単位でアクセスするようにすれば、
論理ブロックのデータ + 訂正用の情報 > 物理ブロック単位でも、性能は劣化
しないと思います。

ITRON/FILE であらかじめ領域を連続ブロックで確保しておくというのは、
物理ブロックを意識してというよりも、ディスクブロックのアロケート時間
(空いているブロックのサーチ時間) の方を意識しているのではないでしょう
か?

# 誰か、この辺のことを知っている人はいませんか? > all

> naitoh_r> もちろん、ファイルがどのようにディスク上に展開されるかというフォーマット
> naitoh_r> 情報は論理単位のサイズを意識する必要があるかと思いますが、それはアプリ
> naitoh_r> ケーション側からは見えないですよね?
>
> そうですね。でも性能の違いとしては見えそうです。

いやまぁ、それはそうですが、そこら辺はファイルシステムの設計と実装の腕
の見せどころでしょう。# と言ってみる。

> naitoh_r> なるほど、データ破壊は起きるが、小さなデータ破壊よりは広い領域に渡って
> naitoh_r> 破壊されることが多いということですね。
>
> 広域というかディスク一台まるごといくような気が。ディスクが
> 回らなくなっちゃたりして。
> # 最近、会社で一台お亡くなりになりました(^_^;)

うーん、こういうディスクを丸ごとこわれてしまう話は、ファイルシステムで
はちょっと救いようがない気がします。
(いや、もちろん、RAID のようなことをすれば別ですが。。。)

> naitoh_r> 具体的にどういうアルゴリズムかは分かりませんが、パフォーマンス悪そうで
> naitoh_r> すね。一回の書き込みにつき、ディスクアクセスが最低 2 回発生することに
> naitoh_r> なりそうです。
> naitoh_r> 書き込むときに、書きこみ前のデータも保存しておいて、書き込み終了時に新
> naitoh_r> しいデータと置き替えるような処理が必要ですよね。でないとき込み中にシス
> naitoh_r> テムダウンするときに対応できませんから。特に書き込みが細切れなサイズで
> naitoh_r> 行われていたりすると。。。
>
> 少なくとも二重の書き込みは必要ですね。NTの実際については
> 下でまとめて。

> naitoh_r> NT の場合の「ロギング」というのはファイルのデータとは別の領域にファイ
> naitoh_r> ルのアクセス情報を保存するのでしょうか? だとすると、データ訂正用の情
> naitoh_r> 報を別の領域に保存するのもあまり変わらないような気がします。
>
> 訂正データとログでは要求されるものが違うと思います。

信頼性の要求度に差はあるかもしれませんが、基本的には両方とも信頼性向上
のためでは?

> naitoh_r> > # アプリケーションのエラーくらいでシステムダウンするのは問題だけど(^_^;)
> naitoh_r> それはまぁ、論外でしょう(でも、どんな OS でもアプリケーションによるシ
> naitoh_r> ステムダウンを起さないことを保証するのは難しいけど。。。)。
>
> NT4.0はペイントブラシである操作をすると落ちる。シビアな
> アプリケーションならともかくなぜお絵描きツールで?
> # GDIをカーネルに移した余波? ちなみにSP2かSP3で修正されている。

GDI をカーネルに移したのは、NT 4.0 からでしたっけ、折角サブシステムを
分離して信頼性を上げているのに、バージョンを上げて信頼性を下げているの
では世話ないですね。
ところで、SP2 か SP3 で修正したのは、OS なんでしょうか? それとも
お絵描きツールなんでしょうか ^_^.

> naitoh_r> えーと、B-Free に限らないと思うのですが、32 ビットモードで動いている
> naitoh_r> OS だと BIOS は使えないのではないですか?
>
> ええと、まずBIOSを使えないわけではないです。適当な権限の仮想
> 86モードでBIOSをコールすれば良いはずです。あんまり効率よくない
> ので普通はやらないでしょうけど。
> それで、ぼくは良く分からないのですが、直接ハードウェアを操作
> する場合、一度の操作でどれだけの連続領域が読み書きできるので
> しょうか。SCSIの場合はかなり大きいサイズの操作ができるようです
> がIDEの方の仕様が判らなくて。
>
> naitoh_r> それはともかく、データ訂正の機能を入れてもディスク資源のコストとアクセ
> naitoh_r> ス時間についてはあまり気にしないでもよさそうですね。
>
> 一度に読み書きできるサイズが幾らでも(63セクタ以上はあるはず)
> それ以下の適当なサイズを単位として前回書いたのと同じ方法は
> とれるので方法としては問題ないと思いますけど。

> naitoh_r> ふむふむ。特別な API がないということは NT ではファイルの書き込みを行
> naitoh_r> うごとにディスクへ確実に書き込むことを保証しているわけですね。
>
> いや、そんなことは保証しませんよ。NTFSで保証しているのは
> ファイルシステムの不整合が起きないことです。アプリケーション
> がファイルを作った直後にシステムクラッシュしたら、再起動した
> ときにファイルができているかどうかは分かりません。分かるのは
> ディレクトリエントリにファイルがあるのに実際には存在しない
> というようなことはないということだけです。
>
> naitoh_r> # キャッシュとかはどうなっているんだろうか? 普通、書き込み処理は、
> naitoh_r> # 直接ディスクへは書き込まず、キャッシュ上に書き込んでおいて、後から
> naitoh_r> # (ゆっくりと) ディスクに書き込むものと思いましたが。。。
>
> ロギングはキャッシュフラッシュ時の動作になります。まず
> ログを書き出してからフラッシュし、そのあと完了のログを
> 書く。ブロック単位でそれを繰り返すのでしょうね。全体と
> しては2倍のコストかな? もっと細工はしてるでしょうけど。

なるほど。NT については了解です。
しかし、キャッシュをフラッシュするタイミングで同期をとっているとすると、
アプリケーションにとってはあまりメリットがないですね。
結局、アプリケーションが書き込んだつもりの情報が物理ディスクでは存在し
ないことが有り得るわけですから。。。

p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d