このページの最後へ 前の項目へ 表紙へ

Section 3: 設定について

3.1) ADFSBuffers って何?どう設定するのが良いの?

ADFSBuffers とは、 Archimedes が ADFS を使用する際の、 Read Ahead および Write Behind に使用するバッファのことです(訳者注:先読みとwrite-backキャッシュ用のバッファという意味かもしれません)。 これはファイル操作の速度を向上させるために作られました。 しかし、これを使用することによる副作用もあります。 RISC OS v2.00 および v2.01 で使用する場合、フロッピーディスクドライブからディスクを抜く場合は dismount (訳者注: unmount )する必要があります。 これを忘れると、 dreaded (訳者注:ディスクからの読み込み?)時に「Filecore in use.」エラーが起こります。 スピードを犠牲にしても良ければ、 ADFSBuffers の値を 0 にすることでこれを防ぐことができます(と聞いています)。

A5000 の古いモデルに付いているような RISC OS v3.00 の場合、上に書いてあるのとは違う問題が起こるので、この設定を必ず off にしなければなりません。 これを忘れてしまった場合、古いモデルの A5000 でハードディスクを使うとおかしなエラーが起こります。 crucial sector (訳者注:バッドセクタ?)を再フォーマットしたディスクにファイルを保存する時に、 disc address error や general failure が発生するという症状です。 ですので、 RISC OS 3.00 の載った A5000 を使用する場合、必ずこの設定を off にして下さい!

RISC OS v3.10 ではこれらの問題は解決しているのですが、別の問題が発生します。 Namely that if you have only a few ADFSBuffers configured and are accessing the floppy drive then your machine can occasionally lock up completely for you. It appears that any value of ADFSBuffers above 8 causes that problem to be largely alleviated (read it only occurs rarely at these settings). RISC OS 3.10 を使用する場合、 ADFSBuffers の値を 8 以上にすることをお勧めします。 また、この問題を修正する、 ADFSUtils という patch module があります。お近くのディーラーに問い合わせて入手して下さい。

RISC OS 3.5 ではこれらの問題も全て直っているようですし、新しいバグが追加されたということもないようです。

RISC OS 3.5 では、 ADFSBuffers の値は OS によって設定され、この値はお使いの RiscPC に搭載されているメモリの量によって決定されます。 ただし、 RISC OS 3.6, 3.7 および 3.5 に 'extended' FileCore を組み込んでいる場合はこれに当てはまりません。 これらのマシンを使用する場合で、 2GB 以上の区画を持つハードディスクを使用する場合は、 ADFSBuffers を off にしないとハードディスクが使用できません。 このバグは、 Acorn の FTP サイトにある ROM Patch 3 を使用することで回避することができます。

ADFSBuffers の最適な値ですが、 A5000 上で行ったいくつかのテストでは最大の値である 255 を設定した場合、全く設定しない場合に比べて速度が 40 〜 50 %向上するという結果が出ています(これは使用するドライブによって大きく変化します)。 しかし、 32 を設定した場合でも 15 〜 20 %向上します。

要は、 ADFSBuffers はキャッシュとして働くのです。 キャッシュの大きさを増やせば速度は上がりますが、キャッシュの大きさを増やすことで上がる速度には限界があるのです。 よって、 255 を設定した場合は 128 よりもパフォーマンスが良いものの、倍になる訳ではないのです。 しかし、値が低くなった場合はパフォーマンスと設定値が比例関係になり、 64 を設定した場合は 32 の倍のパフォーマンスを示しました。 私としては、基本的に 64 を設定し、あとはメモリの量に応じて増やすことをお勧めします。

目次へ


3.2) RISC OS 3 で solid drag を使いたいんだけど…

Solid drag は、 CMOS RAM に記録されている 28 バイト目のデータの bit 1 で使用するかどうかを切り替えることができます。 このビットを設定することで、 solid drag に「対応した」アプリケーションでは solid drag を使用することができるようになります。 しかし、コマンドラインから *FX コマンドを使用してこのビットを設定すると、困ったことに同じ場所の bit 7 (FileSwitch and the Wimp に関係するスイッチ)も同時に切り替わってしまいます。 従って、このビットを設定するには下にあるような BASIC のプログラムで設定するのが良いでしょう :-

   REM Toggle state of DragASprite bit in CMOS

   REM Read byte
   SYS "OS_Byte",161,&1C TO ,,byte%
   REM EOR byte with mask for bit 1
   byte% = byte% EOR %10
   REM Write byte back again
   SYS "OS_Byte",162,&1C,byte%
   END

これなら他のデータを壊すことなく安全に、 bit 1 のみ書き換えることができます。

目次へ


3.3) ハードディスクの区画はどれくらいの大きさが良いの?

この質問は「こうするべきだ」とはなかなか答えられない質問です。 まずは、使っているハードディスクとファイルシステムから考えてみることにしましょう。 IDE 接続のハードディスクで ADFS をお使いであれば、 ADFS は複数の区画を扱うことができないという制限によって、一つの区画でハードディスク全体を使用することになります( Alsystems PowerIDE のようなサードパーティー製のソフトウェアを使用すれば、一つのハードディスクでも複数の区画を扱えるようになります)。 しかし、ハードディスクをまるまる使うことが常に正しいかと言えばそうでもなく、区画作成時に何メガバイトかを犠牲にすることによってファイルを格納する際の無駄が減り、結果として 10 メガバイトも得をする、ということもあるのです。

RISC OS は、ファイルシステムのオーバーヘッドと速度と柔軟性を考えた結果、かなり複雑な map system を使っています(色々なファイルシステムを共有する FileCore も同様です)。 512Mb 以下の容量を持つディスクであれば問題ありませんが、 何ギガバイトもあるディスクが容易に入手できるようになった現在では、少し無理が生じてきてしまいます。

この辺りを真面目に説明するのは FAQ の範疇を越えてしまうので簡単に書くと、 RISC OS は、ディスク上の最小オブジェクトサイズを示す LFAU (Large File Allocation Unit) の 16 倍のディスク容量を消費するのです。 よって、 2 バイトのファイルでもディスク上では 16 キロバイトの容量を消費してしまいます。 There is an important exception to this involving the sharing of map entries, and thus disc space, but the general rule is as above.(いくつか例外的に働く要素について書かれてる) 下にある表は LFAU とディスク容量、そして最小のオブジェクト(ファイル)サイズの関係を示すものです。

lfau   max disc size   min object
----   -------------   ----------
 1K      499M bytes        16kb
 2K      998M bytes        32kb
 4K     1996M bytes        64kb
 8K     3992M bytes       128kb

上の表を見れば分かると思いますが、区画の大きさを大きくするほど、個々のファイルを格納する際の無駄が増えてしまうのです。 (注意: Image Filing system を使用する場合、このような無駄を気にする必要はそれほどありません)

つまり、区画の大きさを決める場合、そのディスクで何をするかが決め手となるのです。 Replay による動画を主に保存するような場合、個々のファイルは何メガバイトものサイズがあり、無駄になるディスク容量の割合は数%にも満たないでしょう。つまり、ディスク容量を有効に使うことではなく、大容量のデータを保存することが重要になるのです。 一方、ニュースのスプールとして、一つあたり約 7 キロバイトくらいのファイルを何千も保存するような場合は、区画の大きさを小さくすることで無駄になるディスク容量を劇的に減らすことができます。

FAQ 作者の経験としては、 1 ギガバイトを少し下回るくらいの大きさが良いように思えます。

目次へ



次の項目へ このページの最初へ