From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
Subject: [b-free 534] Re: ファイルシステムの信頼性
Date: Thu, 18 Sep 1997 15:25:43 +0900
> 林です。
>
> 簡単なのは標準FDとエラー訂正の組み合わせを許さないことですね。
> 依存しないからといって全ての組み合わせを許す必要はないですから。
区別する話は標準 FD だけではなく、B-Free OS の独自のファイルシステムでも
当てはまる話です。同じファイルシステムでエラー訂正あるなしの 2 種類があ
る場合、ファイルシステムの情報の中にエラー訂正についての情報を含むべき
だと思います。物理的に同じデバイスでエラー訂正を組み込む場合と組み込ま
ない場合があるならばなおさらです。
> naitoh_r> デバイスドライバでエラー訂正をするにしても、ファイルシステムが何らかの
> naitoh_r> 管理を行わないと、区別もできません。
>
> ファイルシステム管轄外に識別符号を入れることもできます。
> # HDならMBRのファイルシステム・タイプで区別するとか。
えーと、MBR のファイルシステム・タイプはその名のとおり、ファイルシステムを
区別するためのものであって、デバイスドライバに対する情報を与えるものでは
ないと思いますが。。。
(MBR のファイルシステムタイプは、有限(最大 255) なので、あまりむやみに取る
のは考えものです)
まぁ、ファイルシステムで使わないが、マウントするときに参照するような領域を
作っておいて、その領域はエラー訂正ドライバとエラー訂正なしのドライバの両方
で同じように見えるようにする方法も取れますが。。。
> naitoh_r> > 一方、ファイルヘッダに
> naitoh_r> > ファイルのCRCを入れる方法はファイルシステム自体を書き直さない限り
> naitoh_r> > 入れられないでしょう。
> naitoh_r>
> naitoh_r> こちらの方を考えています。
> naitoh_r> つまり、ファイルシステムでのエラー訂正は、記憶媒体の物理的なセクタなど
> naitoh_r> とは無関係に実装すべきだという意見です。
>
> 了解しました。ただ何のためにそのようなエラー訂正が必要かは
> 未だに理解できません。エラー訂正の目的は何ですか?
エラー訂正の目的は、やっぱり信頼性でしょう。
ファイルシステム自体にエラー訂正の機能を設けた場合、ハードウェアによる
RAID を使うほど余裕はないが、ファイルシステムの信頼性は欲しいという場合
に有効だと思います。
> naitoh_r> デバイスの信頼性に不安がある場合、デバイスドライバで保証をするようなこ
> naitoh_r> とをする例があるのでしょうか。
> naitoh_r> 残念ながら、聞いたことがないのですが。。。
> naitoh_r> RAID は、デバイスドライバというより、ハードウェアになってしまうし。。。
>
> ないでしょうね。普通は十分に信頼のおけるハードウェアを
> 使うでしょう。ソフトウェアRAIDというのはあったような気が
> しますが、あれはアプリケーションレベルでしたか。
ちょっと調べたところ、以下の論文がありました。
これが林さんのいうソフトウェア RAID かどうかは分かりませんが。。。
「RAID 型ファイルシステム VAFS/HR の構想」
情報処理学会第 49 回(平成 6 年後期) 全国大会講演論文集(分冊4)
この論文では、RAID (のような) 機能をもつファイルシステムを UNIX 上に作
るという話が載っています。
この中で、デバイスドライバとしてインプリメントすべきか、ファイルシス
テムとしてインプリメントすべきかの考察も行っています。比較項目として性
能、移植性、開発規模の 3 つを挙げています。
ちょっと長いけども引用します。
============================================================
(1) 性能比較
デバイスドライバ層に実装するよりファイルシス
テム層に実装した方が性能は良い。その理由は,次
の三つである。
第一に,UNIX ファイルシステムは同期ファイルア
クセス方式を採用しているが,ファイルシステム層
に実装する場合にはこれに手を加え非同期化するこ
とが可能である。
第二に,図 1 に示すようにパリティ生成単位を
ファイルの論理ブロックとすることができ, たとえ
ファイルがディスク装置上の物理的に不連続に配置
されるような場合でもパリティ生成に伴うI/O数を最
小にすることができる。
第三に,ファイルシステム層で管理しているシス
テムバッファを使用してパリティ生成をすることが
できるため,パリティ生成用の特別なバッファを設
けなくてよくバッファ管理のオーバーヘッドを最小
にすることができる。
(2) 移植性
ファイルシステム層に実装するよりデバイスドラ
イバ層に実装した方が,他の OS への移植やOSのバー
ジョンアップに伴う移植を行いやすい。その理由
は,デバイスドライバ層は入出力インタフェースが
各OSとも公開されているということ,インタフェースの
変化がほとんど無いことからである。
(3) 実装規模
ファイルシステム層に実装するよりデバイスドラ
イバに実装した方が,実装規模が小さくなる。そ
の理由は,ファイルシステム層に実装する場合には
open(),close(),write(),read()などのv-nodeオペレーショ
ンと呼ばれる関数全てを実装する必要があるが,全
てのv-nodeオペレーションはデバイスドライバ層では
READ処理とWRITE処理に帰着されるからである。
ファイルシステム層に実装する場合とデバイスド
ライバ層に実装する場合を比較するとどちらも一長
一短であるが,実装規模が大きくなり移植性が悪く
なっても性能的に有利なファイルシステム層での実
装を選ぶことにした。
============================================================
B-Free の場合移植性はあまり関係ない(他の OS に移植することは
まずないだろうから)と思います。移植性以外の項目では B-Free OS
も同様だと思います。
実装方式も書いてありますが、基本的に RAID と同じようです。
つまり、複数のディスクに対してファイルを分割して格納する方法をとって
います。ファイルのデータとともに、パリティ情報も付加しています。
> ネットワーク型データベースという概念があるのは間違い
> ないのですが、リレーショナル・データベース以前の概念
> です。で、実は詳しいことは良く知らないです。でも、
> データをネットワーク状に関連付けて管理するものだと
> 記憶しています。
>
> naitoh_r> ハイパーテキストのようなものは、普通データベースとは呼ばないと思う。。。
>
> 実身/仮身モデルの場合、データベース的なのはハイパー
> テキストよりもむしろリンクレコードだと思います。即ち
> ネットワーク構造をシステムレベルで把握していること
> です。ついでにいうとレコードタイプをうまく活用すれば
> 検索などかなりデータベースとして使えそうです。
なるほど。林さんのおっしゃっているデータベースファイルシステムという
のは、BTRON ファイルシステムの上に載っているシステムサービスと考えて
いいのでしょうか?
それでしたら、B-Free ファイルシステムでもぜひ入れたいところです。
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d