OSASKのファイルシステム
目次
遅延書き込みの拡張
メディアID
アクセス方法
仮想記憶機構との統合
いきさつ
(上記の４つの説明よりも、こちらのほうがわかりやすいかもしれません)
FATでもi-nodeでもなく・・・
遅延書き込みの拡張
遅延書き込みでお待たせしません
OSASKでは遅延書き込みがサポートされます。
遅延書き込みのために、クローズ処理が完了しても実際の書き込み動作が完了していない場合があります。
このような状態でも、別のアプリケーションがそのファイルをオープンすることができます。
あるファイルをコピーしてその直後にコピー先のファイルを編集したい場合、実際のコピー動作を待たずに編集することができます。
OSASKにおいては、フォーマット動作も「遅延書き込み」の対象になります。
したがって、フォーマットコマンドは一瞬で終了します。
フォーマットが完了するのを待たずに、どんどん書き込んでかまいません。
コピーもリードが済めば、一瞬で終わります(バージョンがかなり進んで遅延リード対応になれば、リードが済まなくても一瞬で終わるようになります)。
ユーザーは、基本的に書き込みが遅延していることを気にかけず、どんどん作業を進められます。
ディスクが入ってなくても読み書きできます
この遅延書き込みは、ディスクがドライブに入っていないときは、ドライブにディスクが入るまで待ちます。
ですから、ディスクが入っていなくても書き込み作業をすることができます(もちろん、実際に書き込むためには、ディスクを入れなければなりませんが)。
また、必要なら、遅延書き込みが完了していなくてもディスクを抜くことができます(もちろん、アクセス中に勝手に抜いてはいけません。
ディスク交換のためのコマンドがあり、それを実行するとアクセスが止まります。
コマンドといっても、「Ctrl+Alt+F1」のような簡単なものになると思います)。
遅延書き込みが完了していないのにディスクが抜かれた場合、当然ですが、残りのデーターはそのディスクが挿入されるまで待機します。
ディスクから一度でも読み込んだデーターは、キャッシュ禁止に指定されていない限り、キャッシュされます。
また、キャッシュされたデーターはディスクを抜いても無効になりません。
そのため、ディスクが入っていなくても(もしくは、違うディスクが入っていても)、キャッシュされていればアクセスできます。
このキャッシュには遅延書き込みの待機分と合わせて、ハードディスクにバックアップされます。
したがって再起動後も有効です。
プリロードもできます
OSASKでは、要求があってから読み込む普通のロードの他に、プリロードという機能も持ちます。
これは、アクセスがあると思われるデーターを要求に先立ってメモリに読み込んでおく機能です。
フロッピーディスクのように遅いデバイスの場合、ディスクが挿入されてから数秒経つと、なにも命令しなくても自動的にプリロードが始まります(もちろん、設定でこの機能を無効にもできます)。
OSASK起動直後によく使うアプリを指定しておけば、起動直後からそのアプリのプリロードも始まります。
基本的には、１．通常読み込み、２．書き込み、３．プリロード、の順で優先順位があり、プリロードが他のアクセスを妨害することはありません。
フォーマット動作も含め、全てのアクセスは割り込みやDMAをできるだけ使うようにするので、バックグラウンドでアクセスしているからといって、CPU負荷が急激に上昇することはありません(これを立証するために、簡単なベンチマークソフトを作る予定です)。
メディアID
キャッシュの管理単位は、ドライブではなく、ディスクです
OSASKでフロッピーディスクにアクセスする場合、Windowsのように「Aドライブ」と指定するわけではありません(注：ドライブレターが使えないわけではありません。
互換性を維持するために、ドライブレターによるアクセスもできます)。
ディスクのそれぞれに名前を付け、それを指定することでディスクにアクセスします。
少し具体的に説明しましょう。
僕が今、３枚のディスクを持っていたとします。
それぞれ、disk-A、disk-B、disk-Cという実にセンスの無い名前です。
disk-A中のファイル"file01"を示すときは、「実際のドライブにどのディスクが入っていようとも」、"/FD/disk-A/file01"と指定します。
このdisk-Aがドライブに入っていなくてもいいです。
このファイルがキャッシュされていれば、ディスクを入れなくてもアクセスできます。
もしキャッシュされておらず、しかもドライブにdisk-Aが入っていなければ、システムウィンドウに「キャッシュ内に無かったのでディスクがドライブにセットされるまで待機している」という趣旨のメッセージが表示されるでしょう。
このように、アクセスには必ずディスク名を示すようになっているので、ディスクを入れ替えたりしても目的のディスクを指し示すことができます。
あなたも僕も、おそらくディスク名は短くてわかりやすいものにするでしょう。
なぜなら、毎回指定するのが大変だと使いにくいですから(GUIインターフェースなら長くても不便じゃないでしょうが)。
短いディスク名ですと、いずれディスク名が衝突するのは目にみえています。
また、友達から借りたディスクがあなたのどのディスクとも別の名前である保証もありません。
もしも、違う内容であるのに同じ名前のディスクが存在したら、OSは混乱してディスクの中のファイルを壊してしまうかもしれません。
これを防ぐために、OSASKはディスクの同一性の判断のために、ディスク名だけではなく「メディアID」というものを使います。
OSASKで管理されるディスクには、メディアIDというものが規定されていて、これは十分に長く、他のコンピューターが発行するメディアIDと衝突することがないように工夫されています。
基本的に、メディアIDはユーザーではなくOSがフォーマット時に発行します。
OSASKがメディアIDが違うのに同じ名前のディスクに出会うと、どちらかの名前を変更して欲しいという警告を出します。
またキャッシュも別扱いになるので、ディスク内のデーターを壊してしまうことはありませんし、キャッシュも混乱しません。
ここでの例はフロッピーディスクだけでしたが、ほかの全てのリムーバブルディスクも同様の方法で管理されます。
アクセス方法
ファイルアクセスは、メモリアクセスと変わりません
OSASKでは、一般的にmemory mapped fileと呼ばれる方法で、ファイルにアクセスします。
ファイルをオープンするときには、セグメントセレクタもいっしょに指定します。
そして、そのセグメントにアクセスすればいいだけです。
＜例(Ｃ言語風)＞
char far *file1 = 0x008400000000;
FILE *fp;
fp = mmopen("file1", "r+b", 0x0084);
file1[100] = 'A'; /* 100バイト目を'A'に書き換える */
・・・
このアクセス方法の場合、フラッシュしなくても即座にファイルに反映されます。
アクセスにバッファを使わないので、高速でもあります。
互換性にも配慮します
OSASKは互換性を重んじるため、一般的なバッファやシークを使ったアクセスもサポートされます。
386系ではセグメントサイズが最大で4GBのため、4GB以上のファイルにアクセスする場合には、バッファやシークを使ったアクセスにするか、もしくはファイルの一部をセグメントに対応づける「ウィンドウモード」でオープンすることになります。
もちろん、4GB未満のファイルであってもウィンドウモードでオープンすることができます。
ファイル全体をロードするわけではありません
OSASKでは、memory mapped fileでのアクセス機構は以下の手順で行なわれます。
オープン時にカーネルは指定されたファイルのサイズを認識し、適当な領域をリニアアドレス上に確保します(この領域は仮想的なもので物理メモリとは異なります)。
そしてその先頭をセグメントのベースアドレスに設定します。
割り当てられた領域はすべてページ不在の状態にし、この段階では実際のロードは行ないません。
実際のロードが行われるのは、このファイルにアクセスしたときです。
そのときになって初めて物理メモリを確保し(4KB)、そこにアクセスされた領域を含む4KBがロードされ、その部分だけページ不在がキャンセルされます。
以降ロードされていない領域へのアクセスがあるたびに、物理メモリは追加され、ロードされていきます。
したがって、何メガバイトにもなる大きなファイルに対するアクセスであっても、その一部にしかアクセスしないのなら、実際のロードやライトもその一部にしかなされません。
仮想記憶機構との統合
OSASKでは、ディスクキャッシュの延長に仮想記憶があります
一般のOSでの仮想記憶機構は、スワップファイルというものを用意し、メモリが足りなくなったらこれと置き換えるという仕組みをとります。
これを逆に捉えれば、メモリが足りていれば、スワップファイルなどは不要であります。
これに対しOSASKでの仮想記憶は、メモリが足りていてもいなくてもハードディスク上のファイルを使います。
上で説明したように、OSASKでは、ファイルへのアクセスはメモリへのアクセスと差がありません。
それならば、メモリを直接使うことをやめ、全部ファイルにしてしまったらどうでしょう。
たとえ全てがファイル上にあっても、ディスクキャッシュと遅延書き込みの拡張のおかげで、そのアクセススピードはメモリと大差ありません。
・・・という突飛な発想を軸にして、OSASKの仮想記憶は設計されています。
普通のOSとくらべて、メモリの扱いが概念的に異なります
OSASKのアプリケーションプログラムにおいては、１セグメントが１ファイルに対応すると考えてください。
プログラムコードはもちろんファイルですが、ワークエリアもスタックもファイルなのです。
それぞれに別々のセグメントを割り振るなら、それは別々のファイルです。
ファイルである以上、必ずディレクトリ構造をとり、ファイル名も存在します。
タスクは１つのディレクトリを構成し、その中にワークエリアやスタックのファイルを持ちます。
もちろん、現在のＣやＣ＋＋で主流のスタックとワークエリアを同一のセグメントに割り当てる方法なら、ファイルも一つです。
OSASKにおいては、「ファイル」が基本です。
もはやメモリは基本ではありません。
アプリケーションの実行速度のことを考えなければ、メモリの存在を意識する必要もありません。
言ってしまえば、メモリは所詮キャッシュ用のバッファでしかないのです。
もしあなたの使っているCPUがL2キャッシュまでサポートしているなら、OSASKの仮想記憶は全メモリをL3キャッシュとして使うようなものです。
そして主記憶はメモリではなく、ハードディスクなのです。
この観点に立てば、メモリの増設はキャッシュメモリの増設ということになるでしょう。
いきさつ
"スワップ"ではない仮想記憶管理
普通にスワップファイルを使った仮想記憶では、「あふれた部分を入れ替える」というのが基本で、仮想記憶の総容量は、「RAMの容量＋スワップファイルの容量」になります。
ですから、あふれなければスワップファイルとのやり取りはありません。
そして入れ替えの際には、メモリ中のデーター（もしくはプログラム）を入れ替え先に書き込みます。
OSASKの仮想記憶は「とりあえず仮想記憶上にあるものは全てハードディスク上に割り当てる」というのが基本で、仮想記憶の総容量は「ハードディスクに割り当てられたファイルの容量」になります。
このファイルはスワップファイルと似たような働きをしますから、仮想記憶の容量はRAMの容量が加えられない分だけ、通常の方法よりも損をしていると言えます。
・・・実際には、普通の方法よりも仮想記憶が小さくなるのではなく、普通の方法よりもハードディスクを多く使うということですが。
しかし、これには利点があります。
まず、読み込みや書き戻しのハードディスク上での位置が変動しないので、スワップ（OSASKではスワップとは言わないのですが、ここでは便宜的にそう書きます）の際に、書き戻しを省略できることがあります。
全く書き換えられることのないプログラムやデーターは、入れ替えの際にハードディスクへ書き戻すことはないのです。
なぜなら、もうそこに書いてあるのですから。
普通の入れ替えタイプですと、メモリ上での書き換えが一度も起きなくても、入れ替えの際には書き戻さなくてはいけません。
なぜならかつてハードディスク上に書いてあったデーターは他のページの入れ替えの際に上書きされてしまっているかもしれないからです。
OSASKの仮想記憶では、書き戻し先と読み込み元の位置は対応していますから、上書きされる心配をしなくていいわけです。
さらに、こんな特徴もあります。
ハードディスク上にファイルがあり、それをメモリにロードした後、何らかの理由でメモリのその部分がスワップアウトされてしまう状況があったとしましょう（これは、珍しいケースではなく、よくあるケースです）。
普通の仮想記憶では、最初にこのファイルをロードするときにディスクアクセスし、スワップアウトの際にはメモリの内容を書き戻すためにディスクアクセスします。
これは結果的に、ハードディスク上のファイルの内容がスワップファイル上にコピーされたことになります。
一方OSASKでは、ハードディスク上にあったものは、新たな割り当てをしないでそのファイルそのものを仮想記憶の一部として扱います。
したがってロードした後に書き換えられていなければ、やはり書き込み過程を省略します。
スワップのためにハードディスク上で同じ内容を持つ部分が２個所できたりはしないわけです。
したがって、先にOSASKの仮想記憶は普通の方法よりもハードディスクを多く消費すると書きましたが、一概にそう決め付けるわけにもいかないのです。
かえって、効率がよいかもしれません。
ディスクキャッシュと仮想記憶の統合
では、ハードディスク上に無いファイルをメモリに読み込む場合では差異がないのでしょうか？
いいえ、ハードディスク上に無いファイルであっても、扱いが異なります。
ハードディスク上に無いファイルであれば、たとえOSASKといえども、ハードディスク上に領域を確保します。
これはハードディスクにコピーされた状態といってもいいでしょう。
これをやらないでおいて、いつでも元のデバイスから読み込むようにすれば容量の節約になりますが、アクセス速度の点から好ましくないです。
・・・それで、ここまでは普通の方法とOSASKでの方法とに結果的な差異はありません。
しかし、ここからが違います。
OSASKの場合、このハードディスク上のコピーは、「キャッシュ(オンディスクキャッシュ)」として活用されます。
OSASKにおけるディスクキャッシュは２つあり、「オンメモリキャッシュ」と「オンディスクキャッシュ」です。
全てのアクセスは最初にオンメモリキャッシュの中を検索され、ヒットすれば実デバイスやハードディスクへのアクセス無しに実行できます。
オンメモリキャッシュがミスヒットした場合、次にオンディスクキャッシュの中を検索します。
オンディスクキャッシュはハードディスク上にあるため、ヒットすれば実デバイスよりも高速にアクセスできます。
もちろん、ハードディスク上のファイルがオンディスクキャッシュに含まれることはありません。
書き込みの際は、即座にオンメモリキャッシュが変更され、デバイスへのアクセスの状態に応じてオンディスクキャッシュ、実デバイスの順に遅延書き込みされます。
普通の仮想記憶はディスクキャッシュとは統合されていないために、このような機能を持っていません。
そして再起動時にはスワップファイルをクリアするのが普通ですが、OSASKではオンディスクキャッシュをクリアしたりはしません。
したがって、再起動後もオンディスクキャッシュを生かせます。
メモリレスアーキテクチャ
一般に、メモリ確保とは仮想記憶中に領域をとることを意味し、普通のOSではそのためのシステムコールが存在します。
そのカーネルは単純にメモリを要求された分だけ用意します。
そして、あふれたらページング管理プログラムが自動的にハードディスクとの間でスワップしているわけです。
つまり、メモリ管理と仮想記憶機構はほぼ完全に独立しているわけです。
・・・OSASKにおいては、仮想記憶を確保するときには、忘れずにハードディスク上に領域を確保しなければいけません。
メモリがあふれていてもいなくてもこれはやらなければいけないのです。
こんなことでは、メモリ確保のシステムコールの処理の大半はハードディスク管理になってしまいそうです。
そうであるならば、いっそのことOSASKでのメモリ管理のためのシステムコールを全廃し、ハードディスク管理として生まれかわらせるというのはどうでしょう？
さらにもう一歩踏み込んで、仮想記憶管理のための専用のハードディスク管理ルーチンを作るのではなく、ファイル管理ルーチンといっしょにしてしまうのはどうでしょう？
・・・このアイデアがひらめいたとき、OSASKにおいてはハードディスク上の一般ファイルと仮想記憶のためのハードディスク上の領域とが、全く同じ扱いを受けていることに気づきました。
唯一の違いは、ファイルには名前があるが、仮想記憶のための領域には名前がないということでした。
・・・それで、そんなわずかな差異のために別々にシステムコールを用意するのはばかばかしいと考えたので、メモリを確保するときに名前を付けさせることにしました。
これはメモリ管理にディレクトリ構造やセキュリティーを導入できる事をも意味し、かえって好ましいでしょう。
・・・こうして、メモリ管理のためのシステムコールは完全にファイル管理のためのシステムコールに吸収されてしまったのです。
メモリを確保するには、仮想記憶というデバイスに適当な名前で新規ファイルを作ることです。
このメモリを解放するときは、このファイルを削除するだけです。
こんないきさつでOSASK上からメモリという概念は一掃されて、メモリレスなアーキテクチャーになったのです。
メインメモリは超巨大なオンメモリキャッシュ用のバッファでしかありません。
メモリがなくなったからといって、全てのアクセス方法が従来のファイルアクセスのようにまどろっこしくなるわけではありません。
メモリを確保するときに名前が必要なだけで、あとはメモリとしてアクセスしていれば、自動的に仮想記憶ファイルが更新されるからです(仮想記憶の進化した形なので当然です)。
このメモリ的なアクセス方法は、仮想記憶へのアクセスだけではなく、普通のファイルにも使えます。
何といっても、両者にはもう何の差異もないのですから。
おかげで、ファイルアクセスは簡単になりました。
それでいっそのこと従来のファイルアクセスのためのシステムコールも撤廃してしまおうかと思ったのですが、それは互換性を損なう恐れがあり、OSASKの精神に反するので思いとどまりました。
(2003.03.21追記)
ええと時々僕のこの「メモリレスアーキテクチャ」が誤解されるので補足しておきます。
基本的にメモリレスアーキテクチャは既存の技術に付け足したという感じのものではなく、既存の技術から削ったという意味合いです。
普通はスワップファイルというファイルシステム上の属性があって、それを使ってOSASKと似たようなアルゴリズムで仮想記憶を管理しています。
OSASKが他と違うのは、そのスワップファイルという属性すらサポートしないで、スワップファイルを一般ファイルにしてしまった上に、スワップファイルがタスクごとにきちんと分かれて存在するということだけです。
・・・何か新しい技術を開発したと主張していると思わないでください。
他と違って、スワップファイルを一般ファイルとして統一的に扱っているだけです。
そのメリットはファイルシステムルーチンが単純になること(仮想メモリ用のアロケートルーチンが不要)と、スワップファイルを分類したりスワップファイルの中身を覗いたりすることが簡単になることだけです(スワップファイルじゃないから当然ですが)。
懸念されうる問題としては、一般的なファイルシステムにおいてスワップファイルという属性は、ファイル名などの各種管理情報を持たなくいていい＝処理が楽、という発想を反映したという観点もあり、その点ではメモリレスアーキテクチャーは処理が増えるのではないかという意見もあります。
その辺は実際に作ってみてテストしないと分かりません。
FATでもi-nodeでもなく・・・
ここの話はOSASKネイティブのファイルシステムの話です。
・・・最初に念を押しておきますが、OSASKではFAT12/16/32やNTFSやLinuxのファイルシステムなど、既存のファイルシステムは全てサポートされる予定です。
それに加えて、OSASKネイティブのフォーマットがあるというわけです。
そしてここではそのOSASKネイティブのフォーマットについて説明したいわけです。
OSASKのファイルに多様な属性が付けられるということは、OSASK-MLログで「タグシステム」を検索すればおおかた分かると思われますので、ここではそれにはふれません。
ファイルがどのクラスタで構成されているかを保持するためのFileAllocateTableのフォーマットについて説明したいと思います。
OSASKの場合FileのことをModuleと呼ぶので、ModuleAllocateTableということになります。
ここではこれを略してMATと書きますが、これを「OSASKのネイティブファイルシステム」の代用として使うことにします。
こうすればFATとごっちゃにならなくていいでしょう。
説明を簡単にするためにここではあえてクラスタサイズを4KBに固定します。
i-nodeとかでは0.5KBだったりするのですが、そういうことをいろいろ書くと長くなるので、必要な人は後で換算してください。
FAT16の場合ですと、この条件では256MBまでしか扱えないのであまり面白くありません。
早速FAT32で考えてみます。
FAT32なら16TBまで扱えます。
これはまあまあいいです。
しかし1クラスタにつき4バイトのFileAllocateTable領域が必要ですので、全クラスタ数の1/1024の容量はFileAllocateTableに食われることになります。
つまり100GBのHDDの場合、100MBはファイル管理のためだけに使われるわけです。
もちろんこれは0.1%程度ですから、惜しくはないといえるかもしれません。
でもメモリにはおそらく入りきらないでしょう。
必要な部分だけを常に持ってくるように工夫すればメモリにうまく収まるかもしれませんが、それでもディスクキャッシュをかなり圧迫するでしょう。
i-nodeの場合も、もし仮にディスクがいっぱいになるまで使えば、結局はFileAllocateTable領域がたくさんできます。
クラスタ番号を32bitで表現していれば、全クラスタ数の1/1024の容量が食われることは避けられません。
i-nodeはFAT32などとは異なりランダムアクセスに有利で大変すばらしいですが、総クラスタ数に比例して管理領域が必要になるということには変わりありません。
ちなみにNTFSはどうなっているのか知りません。
まあ似たようなものじゃないかと勝手に思っていますが。
MATでは、管理領域にクラスタ番号を書くのではなく、バイト単位で書くというルールがある(もちろん僕が勝手に決めたわけですが)ので、32bitでは4GBまでしか扱えないことになり、面白くありません。
ということでHDDなどは64bitアドレスを使います。
これならクラスタサイズがなんであれ16ExaB(16エクサバイト)まではカバーできるので、とりあえずOKでしょう。
・・・しかしこの方法でFAT32的方法やi-node的方法を使うと、1/512の容量が管理領域に食われることになり、より一層面白くないわけです。
FAT32やi-nodeをよく見ますと、「ほとんどの場合、ファイルシステム上の次のクラスタは論理クラスタ番号の次の値になっている」という傾向があります。
つまり、「5 6 7 8 9 10 11 23 24 25 56 57 58 59 60」みたいな感じで、数字が並んでばかりなのです。
サイズを愛し、それゆえに圧縮を愛する僕としては、こんな冗長なものが並んでいるのは許せません。
「(7, 5), (3, 23), (5, 56)」つまり「7 5 3 23 5 56」にしたらいいじゃないかと思いました。
最初の数字は連続する個数で、後ろの数字は最初の番号です。
これが基本的なアイデアです。
大きなファイルでもほとんどの場合、数個にしか分割されていません。
だからこの方法は効きます(と思っています)。
実際はランダムアクセスを速くするためにもうちょっと違う形式になっています。
「7 5 10 23 15 56」みたいな感じです。
つまり、0-6までは5からの7クラスタ、7-9までは23からの3クラスタ、10-14までは56からの5クラスタ、という風に読みます。
これだと目的の位置を2分検索で探せるのでランダムアクセスも速いです。
なお、この開始クラスタ番号(MATではただの64bitアドレスなんですが)にinvalidな値を書けば、それはholeとして扱うという機能も含んでいます。
また不幸にもファイルがいくつにも分割された場合、このテーブルは1クラスタにおさまらなくなるでしょう。
その場合はB*-tree的な階層構造を取るのですが、これは説明が面倒なので省略します。
なお分割数が1、つまり全く分断されていない場合(そしてこれに該当するケースはかなりの割合になりますが)、タグは管理構造へのポインタではなくファイルが存在する最初のクラスタをそのまま指し示すので、MAT領域を全く消費しません。
また管理領域は1クラスタに満たないサイズ(たとえば96バイトとか)ばかりになりますので、MATでは1クラスタに満たないデータの取り扱いが充実させてあります(クラスタ番号を扱わずに普通の64bitアドレスを使う理由もこの辺に関係していますが)。
・・・なお現在のOSASKも、物理メモリ管理に関してはこれと似たようなアルゴリズムでやっています(ファイルシステムがまともになったらもちろん統合します)。
このような方式ではファイルの分断を防ぐごとが特に有効になってきます。
ということでOSASKでは最初からその観点で設計してきました。
まず2つのファイルサイズを作りました。
アロケートサイズと実サイズです。
アロケートサイズというのは、実サイズよりも大きく頻繁にファイルサイズを変える場合などに有効になるものです。
つまり実サイズはバイト単位で細かく変化してもアロケートサイズは64KB単位などで大きくしか変わらない、みたいなことができます。
これで分断の可能性を減らします。
なおアプリからはアロケートサイズは見えません。
またサイズ変更が頻繁でなくなれば、シェルを使ってアロケートサイズを実サイズと同じにしてしまってもいいわけです(受信したメールなど、最初からサイズ変更の可能性が皆無のものは結構あります。
そういうものは最初からアロケートサイズ＝実サイズにするでしょう)。
・・・またOSASKのファイル関係のAPI仕様にもその思想は現われており、ファイルにだらだらと出力していってサイズがその都度拡張していくというのではなく、まずアプリが目標のサイズにして、そしてそこに書き込むというスタイルを採っています。
この仕様も、サイズが小刻みに変化することを抑止するので、マルチタスク環境下にあっても結果的に過剰な分断を防ぐことができるでしょう。
MATでは小さな管理領域で多くのユーザ領域を管理できることになり、これが管理領域のキャッシュヒット率を高め、ひいてはアクセススピードの上昇を期待しています。
ファイルの分断を防ぐということは、シーケンシャルアクセス時のHDDなどのシークが減るということでもあり、これもアクセススピードの上昇に貢献するでしょう。
・・・なお、この説明を書くのが大変遅れましたが、これはOSASKの初期の頃から考えていたアルゴリズムなので、OSASK-MLのログを探せば該当する記述を見付けられるかもしれません。
デフラグすると空き容量が増えるみたいなことを何度か書いたような気がします(これはつまり、ファイルが連続するように再配置すれば管理領域が減って、結果的に空き容量を増やせるという意味です)。
このページに関するお問い合わせは川合秀実(kawai@imasy.org)まで
OSASK計画のページへ戻る