> うーん、論理ブロックのバイト数と物理媒体のブロックのバイト数とは、
> 対応していなくてもいいと思う方に一票 ^^;。
現実にハードディスクが512byteセクターとはいわれてみても
内部的には、訂正コードやデータの複製が2,3回書き込まれているものが多い
はずで、媒体とディスク外への情報が異なっている場合が多いのです。
昔、minixのディスクデバイスドライバを書いていた時に媒体は、2枚で4ヘッドの
はずなのに、ディスク外には8ヘッドのドライブとした情報がでているのが、
ありましたから。それに製造過程で発生した欠陥は、ハードディスクのファーム
ウエアで、修正され代替セクターに書き込まれているはずだと記憶しています。
>
> しかし、考えてみるとチェック情報とデータとは分けてしまった方がいいかも
> しれません。データ破壊が局所的でなく大域的にまとめて起こるならば、デー
> タ破壊と一緒にチェック情報も壊れてしまう可能性が大です。そうすると、
> チェック情報はデータとは別にファイル管理情報と共に入れておく方が安全な
> 気もします。大域的にデータ破壊が起きるとデータ訂正は難しそうですが、
> どのくらい破壊されたかは分かるだけでも助かりますから。
私も分けてしまったほうがいいと思います。
大局的にまとめてデータ破壊が起こるのならば、fsckのときにデータ復元を
行うのは、どうでしょうか?
そうすれば、boot時に復元用データをとっておいて動きがおかしいときに
fsckをかける。ただし、boot後のジョブはすべてパーになりますが。
やっぱり、こまめにバックアップするのが一番ということで、あたらしい
コマンドを作ってジョブ中に復元用データをとるようにする。
こういうのは、どうでしょうか?
私が、crcをファイルパーミッションに入れようといったのは、b-freeが
完全に安定する間での期間、お互いにファイルが壊れていないかの
確認のためにファイルサイズのように簡単にわかればなぁと思って
発言したのです。
h_ike@ma4.justnet.ne.jp