[OSASK 552] Re: 「OSASKのファイルシステム」.

[n-hashi !Atmark! interlink.or.jp]

やっほぉ、<川合の旦那>
[2000年4月10日(月)]にもろた
【[OSASK 550] Re: 「OSASK のファイルシステム」.】への返答っ! 。

川合>  内容もさる事ながら、文の調子があやしいんでしょ？キャッチフレー
川合>ズが並んでて、しかも良さそうなことばかりが書いてあるから。・・・
川合>確かに、言われてみるとなんかそういう感じもするね。

そそそ(;^^)
某M$やImpre$$とかに近い文体(笑)

川合>  でもでも、「遅延書き込みの拡張」「メディアID」「アクセス方法」
川合>の３項目については、長所ばかりになっても仕方ないかもしれません。
川合>長所しかないから（笑）。僕自身、未だ短所を見つけていません（やや
川合>自信あり）。・・・あ、強いて言うなら、初心者にはわかりにくいって
川合>ことくらいかな。

んと、遅延書き込みに関して言えば、
電源面で言えば結構不効率な面があるかもしれません。
状況にもよるけど、現状のOSと比較してHDDの回る時間が長くなるのでは？
稼動部分の消費電力を考えた場合、結構割を食うところもありそうな
気がします。
＃もっとも現状のもそう変わったものではないと思うけど。
遅延書き込み関連の、「電源ぷちっ」はどっちも同じような被害だろうけど
こっちのほうが状況によってはバックアップが取られている可能性が
高い、ということでそれに関しては有利かもね。
＃キャッシュ側、メディア側のどっちかは残っていそうだし。

川合>>しかしまあ、快適に使うにはキャッシュ用に結構容量が必要そうだよね。
川合>  そうなのです。キャッシュしたいディスクの100倍くらいの容量をHDD
川合>に割り当てれば、かなり便利だろうねえ。MOやCD-ROMでは10倍くらいが
川合>精いっぱいだから、あまり快適ではないかもね。・・・といっても、こ
川合>の機能が無いときよりも不便になることはないはず。

実は川合堂はHDDメーカーの走狗(爆)

川合>>・メディアIDうんぬん
川合>>ちと説明がわかりにくいかも。上記の遅延書き込みのところと重複する内容も
川合>>多いので、このあたりはちとフォローが必要なところかもね。
川合>  うん、僕もそう思います。ここねえ、全然うまくまとまらないのよ。
川合>見出しも１つしかないし。
川合>  内容が重複しているのは、ここから読み始める人のことを少しだけ想
川合>定しているせいです（そんなことに配慮しても意味がないのですが）。

そか。単独で読んでちょっと分かったような気がする。

川合>>あと、DISKは必ずDISK名称が必要になるってことだよね。今のような
川合>  いいえ、ディスク名は無くてもいいです。でも、無かったら、ディス
川合>クの抜いた後のキャッシュが無効になるので、キャッシュされることを
川合>前提に考えているんだったら、「必要」です。名無しのディスクでも、
川合>遅延書き込みはできるし（ただし、全部の書き出しが終わるまでイジェ
川合>クトはできない）、一般的なリードキャッシュも可能です（抜いたらキ
川合>ャッシュは無効化されてしまう）。

んー、そかそか。メディアIDのところでいう、disk-Aではなく、
FDにアクセスするようなイメージになるのかな？

ここなんだけど、OS側から仮のDISK名称って発行できない？
当然既存のものと重複しないように、それも一時的に発行されるような代物。
キャッシュの管理をメディアIDでやるようにすれば、不可能ではないような気がするけど。
＃もちろんメディアIDはTAG情報として持たせて表には出ないようにする。

川合>>・仮想記憶機構との統合うんぬん
川合>>うーんと、メモリうんぬんの話がある場合と、ファイルOnlyになった場合、
川合>>私くらいからみると整理されて分かりやすくなったような気分になるけど、
川合>>開発者レベルから見た場合、どのような利点が合ってどういう問題があるのか、
川合>>ってことになるとどうなのかな？
川合>  それは、とても鋭い指摘です。・・・率直に言って、僕にもわかりま
川合>せん（笑）。

うぎゃ。

川合>  利点って何だろう？スワップ制御のプログラムを書かなくていいって
川合>ことかな？（・・・って、OS作る人にしかメリット無いじゃん・・・で
川合>も、これがもともとの動機だったりするので、（笑）とは書けない）。

むう、川合さんの為の機能であったか(笑)

川合>  今までメモリ上にとっていたものでさえ、形式的にでもファイル上に
川合>あると見なすことで、本当によく使うデーターだけが選ばれて、メモリ
川合>上に居座ることになります。これを具体的に説明しましょう。

超整理法？
＃確かアレってよく使うのを（使ったのを）手前に持ってくるってのが
＃ぶっちゃけたところだったような・・・よく知らないけど。

川合>く使われる5MBがメモリ上に残ることになります。たとえ、ディスクキ
川合>ャッシュに空きが多くても、その3MBはディスクキャッシュ用に予約さ
川合>れているので、生かされません。
略
川合>Bが飽和してしまうと、体感上のディスクアクセスが遅くなります。メ
川合>モリはたくさん空いていても、使われません。

要するに融通がきいていないってことだね。

川合>  OSASKの僕が提唱している方法の場合、どちらの場合も純粋に利用頻
川合>度が高いものがメモリ上に残るので（全部ファイルだから、よく使うフ
川合>ァイルが残るわけ。純粋なファイルであってもいいし、従来ならメモリ
川合>に割り当てるような内容のファイルであってもいい）、5:3という比に
川合>縛られることなく、効率があがります。・・・OSASKでなくても、この
川合>比を状況によって自動的に調節する優秀なOSがあれば、「全部がファイ
川合>ル」などいう奇策を用いなくてもいいわけです。

でもまあ、メモリとディスクデバイスというものの役割がはっきりするので、
これからプログラムするような人には、過去のしがらみがない分、
整理しやすくていいだろうね。

川合>  おお！ここまで書いて思い付いた。そう、ロード／セーブっていう概
川合>念がなくなるんだよね。ロードっていうのは、ディスク上のデーターを
川合>メモリに読み込むことでしょ？セーブっていうのは、メモリ上のデータ
川合>ーをディスクに書き出すことでしょ？「全部がファイル」だとメモリな
川合>んていう概念は存在しないわけから、ロードもセーブも無いわけね。・
川合>・・こんなこといわれたら、普通のプログラマーは面食らうよ。わかり
川合>やすいイメージとしては、メモリを経由しないで、直接ディスクに読み
川合>書きしているんだと考えてほしいです。fprintf()やfwrite()などとい
川合>う、「ファイル操作のための特別な関数」は不要なのです。変数を書き
川合>換えればいいんです。それで、ファイルは書き換わります。


これを表面に出すとふぁみこん世代は逆に混乱するぞぉ(笑)

川合>  概念的に「変」であることを除けば、欠点はありません。遅くなるわ
川合>けじゃないし、メモリの利用効率が落ちるわけでもないからです。

そだね。こっちには欠点らしい欠点が「思いつかない」(笑)

川合>  もちろん、「メモリ」という名前のファイルを用意して、このファイ
川合>ルを特別視し、他のファイルからこのファイルへのコピーを「ロード」
川合>このファイルから他のファイルへのコピーを「セーブ」と呼ぶことにす
川合>れば、従来の概念と同じになりますから、新しい概念を受け入れなくて
川合>もプログラムを書けます（概念の互換性）。

しばらく必要かも(笑)

川合>  もう少しML上で議論して、改善方法がつかめたら、再度更新すること
川合>にします。まあ、結局のところ、現物が１日も早くできるに超したこと
川合>はないんだけどね（笑）。

私が勝手に取り込んでいます(笑)

でわでわ

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/  氏名：もしかしたら橋　直行                                      _/
_/  E-mail:n-hashi !Atmark! interlink.or.jp,PXW06256 !Atmark! nifty.ne.jp             _/
_/_/_/_/_/_/_/_/_/_/_/_/_/-----平成12年04月10日(月曜日) PM10時26分_/_/