[b-free 509] OSによるエラーチェックの意味

Takanori Hayashi (takanori@ohsaki.meidensha.co.jp)
Thu, 11 Sep 1997 18:05:11 +0900

林です。

In message <199709110720.QAA06759@ma4.justnet.ne.jp>
"[b-free 507] RE: [b-free 505] Re: それは機械が壊れている"
""hiroharu_ikeda" <h_ike@ma4.justnet.ne.jp>" wrote:
h_ike> > うーん、論理ブロックのバイト数と物理媒体のブロックのバイト数とは、
h_ike> > 対応していなくてもいいと思う方に一票 ^^;。
h_ike>
h_ike> 現実にハードディスクが512byteセクターとはいわれてみても
h_ike> 内部的には、訂正コードやデータの複製が2,3回書き込まれているものが多い
h_ike> はずで、媒体とディスク外への情報が異なっている場合が多いのです。
h_ike> 昔、minixのディスクデバイスドライバを書いていた時に媒体は、2枚で4ヘッドの
h_ike> はずなのに、ディスク外には8ヘッドのドライブとした情報がでているのが、
h_ike> ありましたから。それに製造過程で発生した欠陥は、ハードディスクのファーム
h_ike> ウエアで、修正され代替セクターに書き込まれているはずだと記憶しています。

それは間違いの無い所で、しかしそれは完全にディスクが隠蔽して
いるのでソフトウェアを書く人間には関係の無いことです。しかし
B-Free OSでさらにブロックの再分配をやると、少なくとも他のOS上
からB-Freeのファイルシステムを読もうとしたときには分かり難い
処理が必要となりそうです。
一方、現実にディスクが自身でエラー訂正を行っているとしたら
その上にOSでもチェックをするというのは屋上屋を重ねる行為で
しょう。

h_ike> > しかし、考えてみるとチェック情報とデータとは分けてしまった方がいいかも
h_ike> > しれません。データ破壊が局所的でなく大域的にまとめて起こるならば、デー
h_ike> > タ破壊と一緒にチェック情報も壊れてしまう可能性が大です。そうすると、
h_ike> > チェック情報はデータとは別にファイル管理情報と共に入れておく方が安全な
h_ike> > 気もします。大域的にデータ破壊が起きるとデータ訂正は難しそうですが、
h_ike> > どのくらい破壊されたかは分かるだけでも助かりますから。
h_ike>
h_ike>
h_ike> 私も分けてしまったほうがいいと思います。
h_ike> 大局的にまとめてデータ破壊が起こるのならば、fsckのときにデータ復元を
h_ike> 行うのは、どうでしょうか?
h_ike> そうすれば、boot時に復元用データをとっておいて動きがおかしいときに
h_ike> fsckをかける。ただし、boot後のジョブはすべてパーになりますが。
h_ike> やっぱり、こまめにバックアップするのが一番ということで、あたらしい
h_ike> コマンドを作ってジョブ中に復元用データをとるようにする。
h_ike> こういうのは、どうでしょうか?

上記の「ディスク自体がエラー訂正している」という仮説に立てば
訂正しきれないデータ破壊が起きた場合は、間違ったデータが読み
出されるのではなくて、読み出し要求がエラーを返すと思います。
だからエラー検出のための情報も要らないのではないかと思います。
ディスクのハードウェアでやっている以上の信頼性を求めるには
ソフトウェアRAIDくらいしないといけないと思いますが。FATでの
FATテーブルみたく、全データを二重に書き込むようにしますか?

h_ike> 私が、crcをファイルパーミッションに入れようといったのは、b-freeが
h_ike> 完全に安定する間での期間、お互いにファイルが壊れていないかの
h_ike> 確認のためにファイルサイズのように簡単にわかればなぁと思って
h_ike> 発言したのです。

CRCはファイル構造を反映するわけではないからファイルシステム
のバグによるファイル異常の検出にCRCが向くとは思えませんが。
# CRC値が二つのマシンで異なってもどちらかのファイルが壊れてる
# とはいえない。CRCの計算方法にもよりますが…。

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