From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
Subject: [b-free 503] Re: それは機械が壊れている
Date: Thu, 11 Sep 1997 09:36:09 +0900
> 林です。
>
...[snip]...
> naitoh_r> ソフトウェアでやるとしたら、ディスクの物理セクタとは別の論理的なデータ
> naitoh_r> 単位で付加情報をつけることになると思います。つまり、ファイルシステムに
> naitoh_r> 1K バイト書き込む毎にディスクには 1K + パリティ情報が書き込まれるとか。
>
> いや、だからその論理単位が1020byteとかだと気持ち悪いのではないかなと。
> 目的がディスク読み書きのチェックなのでデータとチェックコードはアトミック
> に読み書きされることが是非とも必要なわけです。そうすると現在のディスクの
> 読み書き単位は512byteなので、データ+チェックコードのサイズが512byteの
> 倍数、そうするとデータ部分はそれに欠ける値にならざるを得ません。しかし
> それは普通のデバイスの単位から考えるとかなり奇妙なものに見えます。
> もちろんファイルに書き込むときに論理単位の大きさを気にするなんて無意味
> だという考え方には一理あります。しかしBTRONやITRON/FILEの仕様は論理単位
> の大きさをかなり意識しているので無視するのも難しいです。
> # 論理単位は1Kbyte=1024byteです。
> # 実際の1Bのハードディスクでは4Kbyte単位ですけど、それも1Kbyteの倍数。
うーん、論理ブロックのバイト数と物理媒体のブロックのバイト数とは、
対応していなくてもいいと思う方に一票 ^^;。
しかし、考えてみるとチェック情報とデータとは分けてしまった方がいいかも
しれません。データ破壊が局所的でなく大域的にまとめて起こるならば、デー
タ破壊と一緒にチェック情報も壊れてしまう可能性が大です。そうすると、
チェック情報はデータとは別にファイル管理情報と共に入れておく方が安全な
気もします。大域的にデータ破壊が起きるとデータ訂正は難しそうですが、
どのくらい破壊されたかは分かるだけでも助かりますから。
ところで、BTRON ファイルシステムの API の仕様では、論理単位の大きさを
意識しているところというのは、どういうところでしょうか?
論理単位を意識するような API は、いっそのこと変更してしまった方がいい
ように思います。
もちろん、ファイルがどのようにディスク上に展開されるかというフォーマット
情報は論理単位のサイズを意識する必要があるかと思いますが、それはアプリ
ケーション側からは見えないですよね?
> naitoh_r> 確かにエラー訂正を標準で行う必要はないと思います。
> naitoh_r> 特に最近の(それなりに)信頼性の上がったハードウェアでは、データ破壊もそ
> naitoh_r> う起きないでしょう。
>
> いや、データ破壊自体は結構おきますよ。でも起きるのはたいていディスク
> クラッシュです。で、そういう場合はディスクの二重化でもしておかない限り
> データは救えません。ちょっとしたデータ訂正くらいでは無意味でしょう。
なるほど、データ破壊は起きるが、小さなデータ破壊よりは広い領域に渡って
破壊されることが多いということですね。
> naitoh_r> 標準でエラー訂正が入ったファイルシステムをサポートするというのもそれは
> naitoh_r> それで B-Free OS のウリになるとは思いますが。電源をズドンと落としても、
> naitoh_r> 平気で立ち上がってくる OS とかいって(DOS か?)。
>
> この目的にはNTFSでやっているようなロギングファイルシステムの方法が
> 良いでしょう。必要なのはエラー訂正ではなくて書き込み完了のチェック
> です。実際、NTはシステムダウンしてリセットしてもちゃんと立ち上がって
> きますから。
具体的にどういうアルゴリズムかは分かりませんが、パフォーマンス悪そうで
すね。一回の書き込みにつき、ディスクアクセスが最低 2 回発生することに
なりそうです。
書き込むときに、書きこみ前のデータも保存しておいて、書き込み終了時に新
しいデータと置き替えるような処理が必要ですよね。でないとき込み中にシス
テムダウンするときに対応できませんから。特に書き込みが細切れなサイズで
行われていたりすると。。。
NT の場合の「ロギング」というのはファイルのデータとは別の領域にファイ
ルのアクセス情報を保存するのでしょうか? だとすると、データ訂正用の情
報を別の領域に保存するのもあまり変わらないような気がします。
> # アプリケーションのエラーくらいでシステムダウンするのは問題だけど(^_^;)
それはまぁ、論外でしょう(でも、どんな OS でもアプリケーションによるシ
ステムダウンを起さないことを保証するのは難しいけど。。。)。
> naitoh_r> ただ、ハードウェア資源の消費については、今のハードウェア環境ではかなり
> naitoh_r> 余裕があると思うので、コストはあまり気にする必要はないと思います。
> naitoh_r> (2GB のディスクで 100MB をエラー訂正に使っても、あまり気にならないでしょ
> naitoh_r> う?)
> naitoh_r> むしろ、エラー訂正のための処理を追加することによってファイルシステムの
> naitoh_r> 性能が劣化する方が心配です。
> naitoh_r>
> naitoh_r> 逆にいえば、何かのウルトラ C 級のアルゴリズムを使えばエラー訂正をして
> naitoh_r> も性能が落ちないならば、何も考えずに標準で入れてしまっても、いいと思い
> naitoh_r> ます。
>
> BIOSを使う場合、一呼び出しで読み書きできるのは連続する63セクタです。
> この63番目のセクタを1〜62セクタの訂正コード用として、実際のディスク
> への読み書きは常に63セクタ単位で行うようにすれば、ディスクアクセスの
> コストはディスク領域のコストとほぼ同等ですね。チェック計算のコストは
> 別ですが、時間的にはディスクアクセスよりずっと小さいので無視できる
> でしょう(CPU消費はあるけど)。先に問題にしたアトミック・アクセスも
> 解決できるのでバランスは良いと思います。
> # この方法によるディスク消費は2GBあたり31MBくらいです。
> # セクタ当たり訂正コードとして約8byteが使えます。
>
> 計算してみると思ったよりコストが掛からないようですね。読み書きが
> 必ず63セクタ単位になりますが、デバイスマネージャでキャッシュすれば
> 良いことですし。データ訂正に意味があるかは疑問ですが、やっても問題
> ないレベルではありますね。
えーと、B-Free に限らないと思うのですが、32 ビットモードで動いている
OS だと BIOS は使えないのではないですか?
それはともかく、データ訂正の機能を入れてもディスク資源のコストとアクセ
ス時間についてはあまり気にしないでもよさそうですね。
> naitoh_r> これは、BSD などでやっている Log-structured file system とは違うのです
> naitoh_r> よね? むしろ、ジャーナルファイルシステムに近い?
> naitoh_r> このアトミックな操作の結果を保証するのは重要そうですね。
> naitoh_r> ひょっとすると、ファイルシステムの API の追加が必要かもしれませんが、
> naitoh_r> B-Free FS に入れてもいいと思います。
>
> Log-structured file system もジャーナルファイルシステムも良く
> 分からないですけど、感じとしてはジャーナルファイルシステムです
> かね。ファイルシステムのAPIの追加は要らないと思いますよ。NTFS
> にもそれようのAPIはないはずですので。ファイルの中身のデータまで
> 保証しようとするとどうなるかは判りませんが
ふむふむ。特別な API がないということは NT ではファイルの書き込みを行
うごとにディスクへ確実に書き込むことを保証しているわけですね。
# キャッシュとかはどうなっているんだろうか? 普通、書き込み処理は、
# 直接ディスクへは書き込まず、キャッシュ上に書き込んでおいて、後から
# (ゆっくりと) ディスクに書き込むものと思いましたが。。。
> naitoh_r> > ディスクでデータ破壊というと一番ありそうなのがディスク
> naitoh_r> > クラッシュです。この場合、広い範囲でデータが壊れるので
> naitoh_r> > 対処するならRAIDみたく2台のディスクに同じデータを書き込む
> naitoh_r> > とかいった対応が必要でしょう。で、こういうのはオプション
> naitoh_r> > としてはありでも基本機能に入れるのは大袈裟ですね。
> naitoh_r>
> naitoh_r> やっぱり、大袈裟ですか?
>
> 同一容量のディスクが2台以上ついているマシンを前提とする基本機能と
> いうのはちょっと問題でしょう。サーバシステム専用になってしまう。
うーん。
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d