[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

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



  こんにちは、川合です。


橋 さんは 2000/04/11 23:43:36 の「[OSASK 557] Re: 「OSASK のファ
イルシステム」.」で書きました:

>川合>  今回概念を統合しているわけだけど、客観的に言って、ここまでセン
>川合>セーショナルにやる必要はありません。今までの概念の延長戦上で、こ
>川合>の仮想記憶の手法を穏やかに説明することもできます。
>そっちを望む声もありそうな(笑)

  しょうがないなあ、そっちもやってみるか。

  普通にスワップファイルを使った仮想記憶では、「あふれた部分を入
れ替える」というのが基本で、仮想記憶の総容量は、「RAMの容量+ス
ワップファイルの容量」になります。そして入れ替えの際には、メモリ
中のデーター(もしくはプログラム)を入れ替え先に書き込みます。

  OSASKの仮想記憶は、「とりあえず仮想記憶上にあるものは全てハー
ドディスク上に割り当てる」というのが基本で、仮想記憶の総容量は「
ハードディスクに割り当てられたファイルの容量」になります。このフ
ァイルはスワップファイルと似たような働きをしますから、仮想記憶の
容量はRAMの容量が加えられない分だけ、通常の方法よりも損をしてい
ると言えます。・・・実際には、普通の方法よりも仮想記憶が小さくな
るのではなく、普通の方法よりもハードディスクを多く使うということ
ですが。

  しかし、これには利点があります。まず、読み込みや書き戻しのハー
ドディスク上での位置が変動しないので、スワップ(OSASKではスワッ
プとは言わないのですが、ここでは便宜的にそう書きます)の際に、書
き戻しを省略できることがあります。全く書き換えられることのないプ
ログラムやデーターは、入れ替えの際にハードディスクへ書き戻すこと
はないのです。なぜなら、もうそこに書いてあるのですから。普通の入
れ替えタイプですと、メモリ上での書き換えが一度も起きなくても、入
れ替えの際には書き戻さなくてはいけません。なぜならかつてハードデ
ィスク上に書いてあったデーターは他のページの入れ替えの際に上書き
されてしまっているかもしれないからです。OSASKの仮想記憶では、書
き戻し先と読み込み元の位置は対応していますから、上書きされる心配
をしなくていいわけです。

  さらに、こんな特徴もあります。ハードディスク上にファイルがあり
、それをメモリにロードした後、何らかの理由でメモリのその部分がス
ワップアウトされてしまう状況があったとしましょう(これは、珍しい
ケースではなく、よくあるケースです)。普通の仮想記憶では、最初に
このファイルをロードするときにディスクアクセスし、スワップアウト
の際にはメモリの内容を書き戻すためにディスクアクセスします。これ
は結果的に、ハードディスク上のファイルの内容がスワップファイル上
にコピーされたことになります。一方OSASKでは、ハードディスク上に
あったものは、新たな割り当てをしないでそのファイルそのものを仮想
記憶の一部として扱います。したがって、ロードした後に書き換えられ
ていなければ、やはり、書き込み過程を省略します。スワップのために
ハードディスク上で同じ内容を持つ部分が2個所できたりはしないわけ
です。

  したがって、先にOSASKの仮想記憶は普通の方法よりもハードディス
クを多く消費すると書きましたが、一概にそう決め付けるわけにもいか
ないのです。かえって、効率がよいかもしれません。

  では、ハードディスク上に無いファイルでは差異がないのでしょうか
?いいえ、ハードディスク上に無いファイルであっても、扱いが異なり
ます。ハードディスク上に無いファイルであれば、たとえOSASKといえ
ども、ハードディスク上に領域を確保します。これはハードディスクに
コピーされた状態といってもいいでしょう。これをやらないでおいて、
いつでも元のデバイスから読み込むようにすれば容量の節約になります
が、アクセス速度の点から好ましくないです。・・・それで、ここまで
は普通の方法とOSASKでの方法とに差異はありません。しかし、ここか
らが違います。OSASKの場合、このハードディスク上のコピーファイル
は、「キャッシュ」として活用されます。このファイルに対するリード
アクセスは実デバイスにアクセスできる状態にあっても、ハードディス
クから読み込ませます。書き込みに際しても、まずはハードディスク上
のキャッシュが更新され、その後に実デバイスへ書き戻されるわけです
。普通の仮想記憶はディスクキャッシュとは統合されていないために、
そういう機能を持っていません。そして再起動時にはスワップファイル
をクリアするのが普通ですが、OSASKではキャッシュファイルをクリア
したりはしません。

  一般に、メモリ確保とは仮想記憶中に領域をとることを意味し、普通
のOSではそのためのシステムコールが存在します。そのカーネルは単純
にメモリを要求された分だけ用意します。そして、あふれたらページン
グ管理プログラムが自動的にハードディスクとの間でスワップしている
わけです。つまり、メモリ管理と仮想記憶機構はほぼ完全に独立してい
るわけです。・・・OSASKにおいては、仮想記憶を確保するときには、
忘れずにハードディスク上に領域を確保しなければいけません。メモリ
があふれていてもいなくてもこれはやらなければいけないのです。こん
なことでは、メモリ確保のシステムコールの処理の大半はハードディス
ク管理になってしまいそうです。そうであるならば、いっそのことOSAS
Kでのメモリ管理のためのシステムコールを全廃し、ハードディスク管
理として生まれかわらせるというのはどうでしょう?さらにもう一歩踏
み込んで、仮想記憶管理のための専用のハードディスク管理ルーチンを
作るのではなく、ファイル管理ルーチンといっしょにしてしまうのはど
うでしょう?・・・このアイデアがひらめいたとき、OSASKにおいては
ハードディスク上のファイルと仮想記憶のためのハードディスク上の領
域とが、全く同じ扱いを受けていることに気づきました。唯一の違いは
、ファイルには名前があるが、仮想記憶のための領域には名前がないと
いうことでした。・・・それで、そんなわずかな差異のために別々にシ
ステムコールを用意するのはばかばかしいと考えたので、メモリを確保
するときに名前を付けさせることにしました。これはメモリ管理にディ
レクトリ構造やセキュリティーを導入できる事をも意味し、かえって好
ましいでしょう。・・・こうして、メモリ管理のためのシステムコール
は完全にファイル管理のためのシステムコールに吸収されてしまったの
です。これと同時に、OSASK上からメモリという概念は一掃されて、メ
モリレスなアーキテクチャーになったのです。メインメモリは超巨大な
キャッシュバッファに成り下がりました。

  メモリがなくなったからといって、全てのアクセス方法が従来のファ
イルアクセスのようにまどろっこしくなるわけではありません。メモリ
を確保するときに名前が必要なだけで、あとはメモリとしてアクセスし
ていれば、自動的に仮想記憶ファイルが更新されるからです(仮想記憶
の進化した形なので当然です)。このメモリ的なアクセス方法は、仮想
記憶へのアクセスだけではなく、普通のファイルにも使えます。何とい
っても、両者にはもう何の差異もないのですから。おかげで、ファイル
アクセスは簡単になりました。それでいっそのこと従来のファイルアク
セスのためのシステムコールも撤廃してしまおうかと思ったのですが、
それは互換性を損なう恐れがあり、OSASKの精神に反するので思いとど
まりました。

  ・・・とまあ、こんな感じです。やっぱり、こっちの方がわかりやす
い?結論から入るか、過程から入るかの違いでしかないんだけどね。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.or.jp
Homepage http://www.imasy.or.jp/~kawai/