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

Naitoh Ryuichi (night@bfree.rim.or.jp)
Tue, 16 Sep 1997 00:40:57 +0900

隆一@自宅からです。

From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
Subject: [b-free 515] Re: OSによるエラーチェックの意味
Date: Fri, 12 Sep 1997 13:20:05 +0900
Message-ID: <9709120420.AA08050@clare.ohsaki.meidensha.co.jp>

> 林です。
>
> In message <199709120226.LAA06087@hisoft.soft.hitachi.co.jp>
> "[b-free 512] Re: OSによるエラーチェックの意味"
> "Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>" wrote:
> naitoh_r> えーと、ブロックの再配分というのはどういう意味でしょうか?
> naitoh_r> ハードディスクの内部で物理的な媒体の情報を変換していたとしても、ハード
> naitoh_r> ディスクの外側からは見えない話だと思いますが。。。
> naitoh_r> B-Free OS でも他の OS でもハードディスクの見え方は同じですよね?
>
> この辺は、OS側でやった場合の問題です。ハードウェアでやっている分には
> 内部で1セクタ当たり516byte書いていようと518byte書いていようとソフトウェア
> には1セクタ=512byteにしか見えなくて何ら問題がないわけですが、OSでやって
> いる場合はそうはいかない。少なくともデバイスドライバの作成者(あるいは
> ファイルシステムの作成者)や他OS上でディスクを解析しようとする人には
> 見えてしまう訳です。
> 例えば、論理ブロック1KbyteごとにCRCを4byteいれる場合、物理的なセクタは
>
> 第1セクタ: 第1ブロックの前半512byte
> 第2セクタ: 第1ブロックの後半512byte
> 第3セクタ: 第1ブロックのCRC4byte, 第2ブロックの前半508byte
> 第4セクタ: 第2ブロックの中段512byte
> 第5セクタ: 第2ブロックの残り4byte, 第2ブロックのCRC4byte, 第3ブロックの前半504byte
> :
> (以下省略)
>
> となるわけでしょう。ブロックとセクタの対応は複雑でプログラムが煩雑だし
> CRCの付加/除去のために読み書きのたびにデータをメモリ上でコピーしなければ
> いけないので大変です。性能的なダメージも大きいかも。
> # ブロック単位で扱う場合でも似た処理は必要だけど単位が大きいので負荷は
> # 大分小さくなると思う。

うーん、この計算は計算式一発で終わりませんか?
ほとんどマイクロセコンド単位の計算だと思いますけど。
この辺のことはフォーマットを公開すれば(計算方法をつければなおのこと)、
作る苦労はほとんどない話だと思います。

# どのみち、TCP/IP あたりでは毎回やっている話なので、ブロック毎に附属
# 情報を負荷/除去するというのは、それほどキテレツな処理ではないのでは
# ないでしょうか。

> naitoh_r> 池田さんの書いているエラー訂正(というか破損セクタの検出)は、工場出荷時
> naitoh_r> しかやらないのでは?
> naitoh_r> ただ、読み書き時のエラーの検出は(CRC 等で)行っているはずです。ただ、ハー
> naitoh_r> ドディスク側でチェックしている場合でも OS 側でチェックすることは無駄で
> naitoh_r> はないと思います。
>
> 何度か名前をあげているBootstrap Project2 の記事(No.4)によると、ディスク
> の読み書きに失敗すると何度かリトライして、それでも駄目なときはそのセクタ
> を捨てて代替セクタに切り替えるらしいですよ。

えーと、データエラーのチェックは、FD に限らず HD でも大抵のものは
やっています。FD の場合だとフォーマットにもよりますが、128 バイト
から 1024 バイトのブロック毎に 2 バイトの CRC が附属します。
(FD のフォーマットは、データ以外にも多くの情報が附属しています)
ただ、ハードウェアでチェックしているかといって、ファイルシステム
でチェックする必要はないといえば、そうとは限らないのではないかと
思います。

> ハードウェアと同様のチェックをOSでもやるのは完全には無駄でないにしても
> 限りなく無駄に近いです。やるなら性質の違うことをやりましょう。

これは、反対。
ハードウェアでやっていることは、あくまでもハードウェアレベルでの処理にすぎ
ないと思います。つまり、ディスク上のデータエラーの検出を行っているだけです。
ハードディスクでの信頼性の高さというのは、CRC でのチェックを含めていること
を忘れないでください。素のままで、CRC のチェックもなく、ハードディスクを扱
ったら、それなりのデータ化けがでてきます。

> naitoh_r> 全データはともかく、管理情報の二重化は必要だと思います(FAT に限らず、
> naitoh_r> BSD の FFS でもやっていますし、この位は最近のファイルシステムではもは
> naitoh_r> や必須でしょう)。
> naitoh_r>
> naitoh_r> データについての二重化についてもオプションに入れとくといいかも。
>
> そうですね。これはクラッシュにもある程度対応できて役立つと思います。
>
> naitoh_r> CRC の計算は、ディスクアクセスに比べてそれほど時間はかからないので、
> naitoh_r> 常時走らせていてもいいと思いますが。。。
>
> ファイルヘッダのCRCは良いかも知れませんね。
> # あれ? もしかしてFDフォーマットになかったかな?

これは、ハードウェアレベルでのフォーマットの話でしょうか?

---
B-Free プロジェクト実行中! 詳細はこの Web ページへ
(http://www.b-free.orient.co.jp/)

内藤隆一 (rnaitoh@st.rim.or.jp)