In message <199709100847.RAA07101@hisoft.soft.hitachi.co.jp>
"[b-free 502] Re: それは機械が壊れている"
"Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>" wrote:
naitoh_r> > IBM/XTあたりにそういうのがあったような。Bootstrap Project.2 で
naitoh_r> > BIOS機能一覧をみてたら、INT13の機能にそういうのがありましたよ。
naitoh_r> > セクタごとにCRCだかパリティだかを付けてたようです。
この部分、一部記憶違いがありました。ロングセクタの読み取り/書き出し
はATとPS/2の機能で、セクタごとに4byteのECCを付けているそうです。
# 1セクタ=516byteということか
naitoh_r> > ただこういうのってハードウェアに直接触れるレベルでやるなら良い
naitoh_r> > けどソフトウェアでやるとどこにCRCを書き込むかが問題になりそう。
naitoh_r> > 1セクタ510byteとかするのも変だし、別のセクタにまとめて書くと
naitoh_r> > 書き込みのたびにそのセクタへのread modify writeが発生して性能
naitoh_r> > に響く上にディスクにも負荷が掛かって反って悪そうだから。
naitoh_r>
naitoh_r> うーん、見落としていました(笑)。
naitoh_r> やっぱり、ハードウェアの信頼性が低い時代にはそういう工夫をしていたので
naitoh_r> すね。
でも通常の読み書きは別にあるので特別な用途に使われたのだと思います。
naitoh_r> ソフトウェアでやるとしたら、ディスクの物理セクタとは別の論理的なデータ
naitoh_r> 単位で付加情報をつけることになると思います。つまり、ファイルシステムに
naitoh_r> 1K バイト書き込む毎にディスクには 1K + パリティ情報が書き込まれるとか。
いや、だからその論理単位が1020byteとかだと気持ち悪いのではないかなと。
目的がディスク読み書きのチェックなのでデータとチェックコードはアトミック
に読み書きされることが是非とも必要なわけです。そうすると現在のディスクの
読み書き単位は512byteなので、データ+チェックコードのサイズが512byteの
倍数、そうするとデータ部分はそれに欠ける値にならざるを得ません。しかし
それは普通のデバイスの単位から考えるとかなり奇妙なものに見えます。
もちろんファイルに書き込むときに論理単位の大きさを気にするなんて無意味
だという考え方には一理あります。しかしBTRONやITRON/FILEの仕様は論理単位
の大きさをかなり意識しているので無視するのも難しいです。
# 論理単位は1Kbyte=1024byteです。
# 実際の1Bのハードディスクでは4Kbyte単位ですけど、それも1Kbyteの倍数。
naitoh_r> 確かにエラー訂正を標準で行う必要はないと思います。
naitoh_r> 特に最近の(それなりに)信頼性の上がったハードウェアでは、データ破壊もそ
naitoh_r> う起きないでしょう。
いや、データ破壊自体は結構おきますよ。でも起きるのはたいていディスク
クラッシュです。で、そういう場合はディスクの二重化でもしておかない限り
データは救えません。ちょっとしたデータ訂正くらいでは無意味でしょう。
naitoh_r> 標準でエラー訂正が入ったファイルシステムをサポートするというのもそれは
naitoh_r> それで B-Free OS のウリになるとは思いますが。電源をズドンと落としても、
naitoh_r> 平気で立ち上がってくる OS とかいって(DOS か?)。
この目的にはNTFSでやっているようなロギングファイルシステムの方法が
良いでしょう。必要なのはエラー訂正ではなくて書き込み完了のチェック
です。実際、NTはシステムダウンしてリセットしてもちゃんと立ち上がって
きますから。
# アプリケーションのエラーくらいでシステムダウンするのは問題だけど(^_^;)
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セクタ単位になりますが、デバイスマネージャでキャッシュすれば
良いことですし。データ訂正に意味があるかは疑問ですが、やっても問題
ないレベルではありますね。
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はないはずですので。ファイルの中身のデータまで
保証しようとするとどうなるかは判りませんが
naitoh_r> > ディスクでデータ破壊というと一番ありそうなのがディスク
naitoh_r> > クラッシュです。この場合、広い範囲でデータが壊れるので
naitoh_r> > 対処するならRAIDみたく2台のディスクに同じデータを書き込む
naitoh_r> > とかいった対応が必要でしょう。で、こういうのはオプション
naitoh_r> > としてはありでも基本機能に入れるのは大袈裟ですね。
naitoh_r>
naitoh_r> やっぱり、大袈裟ですか?
同一容量のディスクが2台以上ついているマシンを前提とする基本機能と
いうのはちょっと問題でしょう。サーバシステム専用になってしまう。
--- 林(takanori@ohsaki.meidensha.co.jp)