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

Takanori Hayashi (takanori@ohsaki.meidensha.co.jp)
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では無くても良いです。
でも実装するなら物理的なブロック単位とずれるのは問題です。意図の
通りの性能を出せないということになりますから。

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

そうですね。でも性能の違いとしては見えそうです。

naitoh_r> なるほど、データ破壊は起きるが、小さなデータ破壊よりは広い領域に渡って
naitoh_r> 破壊されることが多いということですね。

広域というかディスク一台まるごといくような気が。ディスクが
回らなくなっちゃたりして。
# 最近、会社で一台お亡くなりになりました(^_^;)

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で修正されている。

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倍のコストかな? もっと細工はしてるでしょうけど。

---
    林(takanori@ohsaki.meidensha.co.jp)