Skip to main content.
Google custom search

NetBSD ドキュメンテーション: カーネル

FAQ - よくあるカーネルに関する質問

よくあるハードウェアに関する質問

さらなる読み物

FAQ - よくあるカーネルに関する質問

どこでカーネルソースをダウンロードできますか (トップ)

公式リリース

すでにインストールされているものと同じリリースのカスタマイズしたカーネルを コンパイルするには、カーネルの syssrc.tgz ファイルだけあれば十分です。 特定のリリースに対して、このファイルは、そのリリースのメインディレクトリーの中の gzip された tar ファイル 'source/sets/syssrc.tgz' にあります。 たとえば、NetBSD 3.1 のカーネルソースは、ファイル /pub/NetBSD/NetBSD-3.1/source/sets/syssrc.tgz にあります。

もし NetBSD CD-Romを持っていたら、 'source/syssrc.tgz' も含まれています。ソースはどこでも展開できますが、 習慣的に /usr/src に置かれます。 展開するには "cd / ; tar xvzpf <ファイル名>" と してください。

'最前線' -current ソース、 冒険好きな人限定!

最新のカーネルソースは ftp.NetBSD.org かミラーサイトの /pub/NetBSD/NetBSD-current/src/sys/ ディレクトリーにあります。 カーネルをコンパイルするには、以下のものを /pub/NetBSD/NetBSD-current/tar_files/src からダウンロードした方が いいでしょう:

あなたが使っているバージョンから変更があった場合、最初に 'config' プログラムをビルドとインストールすべきです。 -current は NetBSD 開発の最先端なので、-current カーネルの コンパイルに関する問題 があるかもしれません。 あなたがコンフィグの手順に慣れるまでは 公式リリース のソースを 使うことをお勧めします。

特定の日付のカーネルソースをダウンロードするには

スナップショットをあなたのマシンにインストールしていて、 カーネルを作り直したい(でも -current カーネルは新しすぎる)場合に、 このような事が必要かもしれません。 anoncvs を用いた NetBSD-current の追跡の方法に従ってください。

カーネルの作り方 (トップ)

以下に示す手順は、インストールされている NetBSD と同じバージョンのカーネルをコンパイルする場合専用のものです。 同じメジャーバージョンの、より新しいカーネルに更新する場合も、 以下の手順を使ってうまく更新できるはずです。しかし、-current のカーネルに更新する場合や、より新しいメジャーリリースに更新したい場合には、 はじめに、新しいツールチェインをコンパイルする必要があります。 -current の追跡に関するドキュメンテーション内にある、build.sh スクリプトを使ってツールチェインと新しいカーネルを構築する方法の説明に従ってください。
カーネルを構築する手順は、以下の通りです。
  1. あなたのベースシステムに付属していたコンパイラーセット(comp.tgz)を インストールしたことを確認してください。
  2. カーネルソースをダウンロードし展開します ( どこからカーネルソースを ダウンロードできますか参照)。
  3. "cd /usr/src/sys/arch/<ARCH>/conf", <ARCH> には 'i386', 'sparc', 'mac68k' のような あなたのマシンアーキテクチャーが入ります。
  4. "cp GENERIC <MYCONF>", <MYCONF> はこの設定にあなたが名づけた名前です。ホスト名や マシンタイプ、あなたの名前を使ってもよいのです。英文字、数字、 そして _ 文字が使えます。
  5. <MYCONF> の編集。 最初はこのステップは飛ばしても構いません。 i386 上で仮想コンソールを得るために 'pc0' をコメントアウトして 'vt0' を有効にしたりするように、 あなたが持っていなかったり使っていない CPU タイプやハードウェア、 デバイスのドライバーを削除することができます。 あなたがどのハードウェアドライバーを使い続けるかを決めるよい第一歩 となるのは、"dmesg" か "dmesg | grep ' at '" の出力を読むことです。 '<XXX> at <YYY>' を含む全ての行について <XXX> と <YYY> の両方のエントリーを残す必要があります。 他のカーネル設定のオプションの情報のために、 options(4) も読んでください。
  6. “config <MYCONF>” を実行します。こうすると、 <MYCONF> に対するカーネル構築用ディレクトリーが作成されます。
  7. "cd ../compile/<MYCONF>" して、 カーネルをビルドするためのディレクトリーに移動します。
  8. "make depend" して、 make プログラムがどのファイルをリビルドすればいいのか わかるように(この時点では全て!)、'.depend' ファイルを生成します。
  9. "make" して、 カーネルをコンパイルします。もし全てがうまくいけば、'netbsd' カーネルができているでしょう。もしあなたが VAX を使っていれば これは相当時間がかかり、大規模な Alpha マシンなら短い時間であり、 残りの人たちはこの中間の時間になります。
  10. "mv /netbsd /netbsd.old ; mv /usr/src/sys/arch/<ARCH>/compile/<MYCONF>/netbsd /" して、 現在のカーネルを保存し、(とても重要)、 新しいカーネルをブートできるよう移動します。
  11. "reboot" して、あなたの新しいカーネルを使ってリブートします - ブートメッセージには次の行が含まれているはずです: 'NetBSD <VERSION> (<MYCONF>) #0: <COMPILE_DATE>'
  12. 何か問題があったら: シングルユーザーモードで 'netbsd.old' カーネルをブートしましょう。 変更する手順はブート手順に依存していますが、 i386 ではこうでしょう:
    1. 最初の NetBSD のメッセージが表示されたら SPACE を押す
    2. "boot netbsd.old -s"
    次にカーネルを元に戻す:
    1. "fsck /"
    2. "mount /"
    3. "mv netbsd.old netbsd"
    4. "exit"

GENERIC カーネルっていったい何なんですか? (トップ)

GENERIC という言葉はマシンアーキテクチャーでサポートされている 全てのマシンで実行できるように設定されたカーネルを意味します。 この言葉はもともとカーネルの設定ファイル中に含まれていた、 設定オプションでもあるルートデバイスを"汎用(generic)"と することを示す行に由来します。このオプションと設定行の書式は すでに用いられていませんが、この名称はしばらく残ることでしょう。

このため、GENERIC カーネルは、全てのデバイスドライバーとたくさんの マシンモデルをサポートするコードを含んでいます。 多くはあなたにとって必要ないものなので、 あなた用のカスタム化したカーネルを コンパイルする事をお勧めします。

mclpool limit reached: increase NMBCLUSTERS ってどういう意味ですか? (トップ)

これはカーネルが、mbuf クラスターにマップした空間を使い果たしたことを意味します。 mbuf クラスターはネットワークコードでパケットやその他の ネットワーク関係のデータを格納するのに使用されています。

デフォルトの NMBCLUSTERS の設定は 1024 (NetBSD 1.5 以前では 256) なので、 もしこの問題が起きたならば、エラーメッセージが出なくなるまで、 この値を倍に増やしていってください。現在の NMBCLUSTERS の値は、以下のように sysctl(8) を使って表示できます: 

	# sysctl kern.mbuf.nmbclusters

または、以下のようにすることもできます 

        # echo 'print nmbclusters' | gdb -q /netbsd

カーネル設定に関するオプションについてのより詳しい情報は options(4) を参照して下さい。 この値を変更するには、 

	options NMBCLUSTERS=2048

をカーネル設定ファイルに加えるか、 カーネルを直接変更してください: 

        # gdb --write /netbsd
        (gdb) set nmbclusters=2048
        (gdb) quit

カーネルを直接変更した場合は、変更が有効になるようにするためにリブートが必要です。 もし、使用中のプラットフォームがサポートしていれば、次のコマンドを用いて 値を設定することもできます。 

	# sysctl -w kern.mbuf.nmbclusters=2048

この方法はすぐに有効になりますが、次回のリブート時には設定されません。 この方法とカーネルの変更を組み合わせれば、新しくカーネルを作る必要も リブートする必要もありません。

WARNING: SPL NOT LOWERED ON SYSCALL EXIT ってどういう意味ですか? (トップ)

このカーネルメッセージはカーネル中に "int x = splfoo();" したのに復帰する前に "splx(x);" を実行しなかった syscall が あるというバグがあることを意味します。 この例で splx(x); 関数はシステムの優先度レベルを x にエンコードされた状態、 つまり他の spl 関数(この場合は splfoo(); という関数)によって返された値に レストアします。

このカーネルメッセージが出力された場合、カーネル内デバッガーである ddb(4) に 入って下さい。ddb 内で 't' を押すことによりスタックトレースを得ることができ、 問題の syscall() を確認することができるかもしれません。 このカーネルメッセージは本来出力されるはずが ないものですので、trace コマンドの出力(ほかの関連情報も含めて)を send-pr(1) する方がいいでしょう。

spl 関数についてのより詳しい情報は spl(9) を参照して下さい。

Stray interrupt on IRQ 7 ってどういう意味ですか? (トップ)

このカーネルメッセージ "Stray interrupt on IRQ 7" は、割り込み コントローラーが、 IRQ 7 上のマスク解除された割り込みを報告したが、 その IRQ で要求されたドライバーがないことを意味しています。

これが起きうる原因は、ふたつあります:

  1. PC 以外では、ほとんどの場合は、その IRQ にドライバーがアタッチされたが、 そのドライバーが不適切だったことを (この場合のほかは、その IRQ がマスクされていたことを) 意味します。

  2. PC では、もっとやっかいな 'default IR7' の問題があります。 これは、デバイスがある IRQ をアサートした時に、 PIC が割り込みを検知した後に CPU がそれを知る前にその IRQ がデアサートされたため、 その IRQ が何だったかについて PIC が公然と嘘をつくのです。

    'default IR7' を前提にするという方法もありますが、 古いマシンの中にはかえって状況が悪化するものもありますし、 一般論としても、まず第一にドライバーを改良してこれを出さないようにした方がよいです。 とはいえ、エッジトリガーな割り込みを使っていると、 完全な予防は困難な場合もありますが。

なお、このカーネルメッセージは、 DEBUG オプション付きのカーネルを走らせているときにしか出ません。

なぜカーネルを -msoft-float 付きでコンパイルするのですか (トップ)

プロセスがシステムコールを呼び出したとき、 後でそのプロセスに戻ってこられるように、 カーネルはプロセッサーの状態を保存する必要があります。 浮動小数点レジスターは比較的大きくなりがちなので、それらを保存したり 回復したりすることは高価な操作です。もし FPU がまだ処理を実行途中であっ たなら、CPU はその処理が完了するまで待ってからでないと、レジスターのコピー を行うことができません。

カーネル内で浮動小数点レジスターを利用するのを避けることで、システムコール実行 の効率を、かなり向上させることができます。 また sparc など、いくつかのプロセッサーでは、浮動小数点コンテキストの切 り替えを lazy に行うことによって、プロセス切り替えの際の浮動小数点レジ スターの保存/回復処理を、場合によっては省略することもできます。

いくつかのアーキテクチャーではコンパイラーは主要な操作 (メモリーブロック転送など) のスピードアップのために浮動小数点レジスターを使うことができ、 上記の動作を止めるためには '-msoft-float' が必要です。

メモリーの少ないマシンでカーネルをコンパイルするとすごい遅いのですが (トップ)

デフォルトでは NetBSD はサポートしているほとんど全てのハードウェアに対する ドライバー、ネットワークプロトコル、ファイルシステムを含む GENERIC カーネルを インストールします。これは、そのポートのいかなる計算機でもそのカーネルが 実行されることを保証しますが、結果として、特にメモリーが少ない計算機では、 必要以上の(メモリー)空間を占有します。また、カーネルのコンパイルの際には -O2 最適化が行われています。コンパイラーが、この最適化を行うことにより 出来上がるカーネルは可能な限り速くなりますが、コンパイルの際には 通常より多くのメモリーと時間を必要とします。

あなた専用のカーネルを構築する 際のひとつの方法としては、コンパイラーに対して通常の使用にとって 十分である最適化のみを行うように指示するために "make COPTS=-O" を使うことです。この結果として できあがったカーネルはほんの少し遅くなりますが、コンパイルにかかる 時間は短くなります。

もし、メモリーの少ないマシンを使用していて、カーネルをカスタマイズ するために何度も 'コンパイル、新しいカーネルでリブート' を繰り返す つもりがあるのならば、始めの何回かは "make COPTS=-O" を使い、最後に "make" を使うのが良いかもしれません。

もちろん、メモリーが少ししかないマシンでカーネルをコンパイルするのに、 一般的にもっとも速い方法は、別のマシンを使用すること、または一時的に もっとメモリーを増設することです!

-current カーネルのコンパイルに関する問題 (トップ)

最初に注意すべき点は、 current-users メーリングリストに参加した方がよいということです。 current-users を読まずに -current を追うことはライトを灯けずに夜道を ドライブしているようなものです。警告しましたよ :)

最新の config.tar.gz をダウンロードし、コンパイル、インストールし、あなたの コンフィグファイルに対して再度 config を実行してください。 (config コマンドはリリースごとにかなり頻繁に変更されますから)

時々、あらかじめバイナリーやライブラリーをアップグレードしておかないと、 リリース版で -current の構築ができなくなることがあります。このような場合、 それらをバイナリースナップショットからインストールした上で -current を構築したほうが簡単かもしれません。 i386 の -current スナップショットは、 (たとえば) /pub/NetBSD/arch/i386/snapshot/ にあります。 src/UPDATING ファイルには、このような、 -current や -current カーネルの構築に際して 知っておくべき重要な変更点に関する情報が載っています。

カーネルクラッシュダンプのデバッグの方法 (トップ)

  1. 同じソースを用いて設定ファイルの中で DEBUG と 'makeoptions DEBUG="-g"' を有効にして カーネルの作成をしたことを 確認してください。
  2. "gdb netbsd.gdb" (カーネルをコンパイルしているディレクトリーで)
  3. gdb プロンプトで "target kvm /var/crash/netbsd.0.core" します。 gdb6 ではなく gdb5 を使っているシステムでは、"target kcore ..." を使います。

一般の gdb(1) コマンドも使えます。例えばバックトレースを得るには 'bt' とします。

カーネルクラッシュダンプをデバッグしているときにバックトレースを得る方法 (トップ)

カーネルのクラッシュダンプをデバッグしている場合、 次の簡単な 2ステップで任意のプロセスのバックトレースを gdb から得ることができます。

  1. LWP の lwp 構造体のアドレスを調べる : ps -ax -O laddr -M netbsd.x.core

    (LWP すなわち軽量プロセスは、一つのプロセス、 またはカーネル内で実行されているプロセスの一つのスレッドに対応します。 非スレッドなプログラムではプロセスに対応するLWPはただ1つで、 スレッドなプログラムでは複数のLWPとなっていることもあります。

  2. このアドレスを使うよう、gdb に "kvm proc 0x<addr>" と指示する

DDB ってなんですか、それを使うと何ができるんですか (トップ)

DDB はオプションとして提供されるカーネル内部のデバッガーです。 次の 3通りの方法で起動することができます:

  • いつでも、ポート特有のキーの組合せで起動する(組合せについては ddb(4) 参照)。
  • カーネルがパニックした時に起動するように設定できます。
  • '-d' をブートフラグに指定する (boot netbsd -d)。

いくつかの有用なコマンドは次の通りです:

  • trace - スタックトレースを作ります。カーネルパニックの 問題報告を送る のにとても便利です。
  • reboot - システムをリブートします。
  • sync - クラッシュダンプを作った後、リブートします

カーネルのクラッシュダンプを作るには (トップ)

通常、カーネルはパニックした時に自動的にクラッシュダンプを生成し、 リブート時に savecore(8) によって回収されます。 しかし、 ddb(4) で sync (または reboot 0x100) を用いると強制的にクラッシュダンプを作る事ができます。もし、 カーネルが buffer キャッシュをシンク(同期)しようとしている間に panic したり ハングするならば、シンクを行わない reboot 0x104 を使うことができます。

ブートフロッピーにカーネルを追加する方法 (トップ)

いくつかのポートでは既に "cd /usr/src/distrib/<ARCH>/floppies ; make " としてブートフロッピーを構築することができます。 (これを実行する前に INSTALL カーネルを手動で構築する必要があるかもしれません。) 既に boot.fsファイルがあるのなら、次の手順でカーネルを置き換え ることもできます:

  1. vnconfig -c vnd0 boot.fs
  2. mount /dev/vnd0a /mnt
  3. gzip -c -9 < netbsd > /mnt/netbsd.gz
  4. umount /mnt
  5. vnconfig -u vnd0

この手順は、コンフィグファイルに "pseudo-device vnd" を指定して 作成したカーネルを、現在利用していることを前提としています。

新しく SCSI デバイスを増設したら、今までマウントできていたデバイスがマウントできなくなってしまいました。いったいどういう規則でデバイスに番号をつけてるんですか? (トップ)

デフォルトでは、NetBSD での SCSI デバイスは SCSI ID 番号の順に 0 から 番号付けされます。いいかえると、一番小さな番号の SCSI デバイスが /dev/sd0 となり、次のデバイスが /dev/sd1 という ふうになります。これはブートプロセスの間に対応づけられる事に 注意してください。

もし、あなた専用のカーネルをコンパイルするならば、 お好きな SCSI ID 番号を示す SCSI デバイスをセットすることができます。 そのためのカーネル設定ファイルは次のようになります: 

sd0             at scsibus0 target 4 lun 0
sd*             at scsibus? target ? lun ?

上の 2行を用いると sd0 は SCSI ID 番号が 4 のディスクとなり、 残りのデバイスは上で述べられたルールで対応づけられます。 これは、しばしば、SCSI デバイスの "hardwiring" と呼ばれ、 RAIDframe や ccd を使う場合には使用することをお勧めします。 こうしておくと、一つのデバイスの電源が入っていなかったり 故障した場合にデバイス ID が変わってしまうことを避けることができます。

よくあるハードウェアに関する質問

device not configured ってどういう意味ですか? (トップ)

  • このメッセージがシステムブートの autoconfiguration の出力中に 現れたのならば、それはカーネルがシステム中に、あるハードウェアを 検出したがそれに対応するデバイスドライバーが無いことを意味します。 これにはデバイスドライバーは存在するがブートに使用したカーネルには 含まれていない場合と、デバイスドライバーが本当に存在しない場合の 両方の可能性があります。 (後者の場合、優しい開発者に連絡を取り、テスト用のハードウェアを 提供してデバイスドライバーを書いてもらいましょう)

    GENERIC カーネルは基本インストールに用いられるので、 安定で動くことが保証されている事が重要です。そのため、 まだ安定ではないデバイスドライバーは GENERIC カーネルに含まれていません。 あなたのシステム用の GENERIC カーネルの設定ファイルを見てみると 「コメントアウト」されている実験的なデバイスドライバーが見つかるかも しれません。もしあなた用のカーネル(それを GENERIC とは呼ばないでください)を コンパイルするならば、実験的なデバイスドライバーを試すことができます。

  • もし、このメッセージが /devにあるデバイスノード (例えば SCSI ディスク)へアクセスしようとしたときに出力されたならば、 それはアクセスしようとしたそのデバイスユニットを見つけられなかった 事を意味します。例えば、存在しない、またはドライバーがカーネルにコンパイルされていない SCSI ディスクにアクセスしようとした場合です。

    しばしば、これは /etc/fstab に書かれたデバイスノードと カーネルがブート時の autoconfiguration で見つけたものが一致しない状態で、 /etc/rc中の "mount" コマンドが全てのファイルシステムを マウントしようとした時に起ります。いま一度、使用しようとした デバイスがブート時にカーネルによって検出されているかを確認してください。 確認には /var/run/dmesg.boot (ブート時の autoconfiguration の 出力のコピーが保存されています) を用いることができます。

    以上のほかに、このメッセージが出力されることがあるのは、 疑似デバイスとして実装されているあるカーネルサブシステムが カーネルにコンパイルされておらず LKM としてもロードされていない場合で、 コンフィギュレーションプログラムがその疑似デバイスを /dev 以下のデバイスノードを使って設定しようとしたときです。 たとえば、防火壁がカーネルにコンパイルされておらず LKM としてもロードされていない場合で、pfctl(8) または ipf(8) ユーティリティーが防火壁のルールを読み込もうとしたときが相当します。 これらのユーティリティーが、 使おうとされたデバイスはどれかなどの有用なメッセージを表示しなかった場合、 コマンド内部で何がおこなわれているかを調べて、 このエラーメッセージの原因を突き止めるには、 ktrace(1) を使うと便利です。

    このほかの多くの場合、このメッセージが出力されることがあるのは、 存在しないデバイスやドライバーのないデバイスにアクセスしたとき、 たとえば、存在しないネットワークインターフェース名が ifconfig(8) に渡されたときなどです (この場合、適切なドライバーが存在するとわかっていればですが、 そのインターフェースを ifconfig vlan0 create のようなコマンドで明示的に作成する必要があるかもしれません — このことは、sl(4), vlan(4), stf(4) など、たいていのネットワーク疑似デバイスにあてはまります)。

ATAPI や ATA (IDE) デバイスのデバッグ (トップ)

もしカーネルが WDCDEBUG を有効にしてコンパイルされていれば、 gdb が wdcdebug_atapi_mask と wdcdebug_mask の値の変更に使用できます。 これらの変数中の適切なビットを設定することで、カーネルは ATAPI と ATA 操作に ついての詳しい情報を出力するようになります。 (現在 NetBSD のデフォルトでは WDCDEBUG は有効になっています。)

最高レベルの出力を得るには次の手順に従ってください: 

	# gdb --write /netbsd
	(gdb) set wdcdebug_atapi_mask=0xff
	(gdb) set wdcdebug_mask=0xff
	(gdb) quit

註: この例の設定は非常に大量の出力を行います。 個々のオプションを選択するためには、次に掲げる行のすぐ上に ある、ビットフラグのリストを見てください:

USB デバイスのデバッグ (トップ)

USB デバイスの問題が起きた場合、USB ドライバーのメッセージを冗長にすることが できます。

  • USB_DEBUG と DDB を含むカーネルをコンパイルする。
  • -d をつけてブートし、 ddb(4) に入る。
  • ddb で変数 usbdebug と uhcidebug を 5 にセットする。 ("write usbdebug 5" と "write uhcidebug 5")
  • デバイスを挿入して continue と入力する。

あたらしい PnP デバイスを認識させるには (トップ)

この手順は対応する汎用のデバイスがすでにサポートされており、 デバイス ID が認識されないだけである時のみ有効です。 動作の異なるデバイスを加えるにはソースコードを書く必要があります。

  1. デバイスは、ブートメッセージ中に 'not configured' として 表示されているはずです。出力中に含まれる デバイス ID を記録して下さい(この例だと USR3031です): 

    isapnp0: <U.S. Robotics 56K FAX INT, USR3031, , > port 0x3e8/8 irq 5 not configured

  2. 適切なエントリーを /usr/src/sys/dev/isapnp/isapnpdevs に加えて下さい: 

    devlogic       com     USR3031         USR 56k Faxmodem
  3. isapnpdevs.{c,h} を 'make -f Makefile.isapnpdevs' として作り直します。
  4. カーネルの再構築をしてください。
  5. 変更点を send-pr(1) または オンラインフォームを用いて 報告して下さい。

あたらしい PCMCIA デバイスを認識させるには (トップ)

この手順は対応する汎用のデバイスがすでにサポートされており、 デバイス ID が認識されないだけである時のみ有効です。 動作の異なるデバイスを加えるにはソースコードを書く必要があります。

  1. カーネルを options(4) PCMCIAVERBOSE を有効にしてコンパイルします。
  2. ブートメッセージをチェックします - 該当のカードは 'not configured' とレポートされているはずです。製造元 (Manufacturer) とプロダクトコード(例題では 0x143 と 0x201 です)を記録します: 
    pcmcia0: CIS version PCMCIA 2.0 or 2.1
pcmcia0: CIS info: Grey Cell, GCS2000, Gold II, 1
pcmcia0: Manufacturer code 0x143, product 0x201
pcmcia0: function 0: network adapter, ccr addr 3f8 mask 1
  3. ベンダー(vendor) と プロダクトコード(product) を /usr/src/sys/dev/pcmcia/pcmciadevs に加えます
  4. pcmciadevs.h と pcmciadevs_data.h を 'make -f Makefile.pcmciadevs' として作り直します。
  5. 付け加えたエントリーを適切な /usr/src/sys/dev/pcmcia/ にある bus attach ファイルの先頭部分にあるデバイステーブルに付け加えます。 例えば ne2000 互換カードの場合には /usr/src/sys/dev/pcmcia/if_ne_pcmcia.c に加えます。
  6. カーネルの再構築をします。
  7. 変更点を send-pr(1) または オンラインフォームを用いて 報告して下さい。

PLIP (Parallel Line IP) をサポートしていますか (トップ)

NetBSD/i386 で PLIP をサポートするための Martin Husemann のパッチが PR 1278 として出ています。この PR の末尾にあるパッチは、NetBSD 1.3.3 ソースツリーに対して適用することができます。

UBC ってなんですか? (トップ)

UBC とは統合されたバッファーキャッシュ(Unified Buffer Cache) プロジェクトを 意味します。これは Chuck Silvers によって書かれ、1.5L(2000年11月)以降の NetBSD に統合されています。UBC でない状態からセットアップする際には config(8) を再実行する必要がありますが、その前に "BUFCACHE", "NBUF" や "BUFPAGES" の設定を消去して、バッファーキャッシュのサイズをデフォルトに 戻した方が良いかもしれません。UBC のもとでは、伝統的な バッファーキャッシュは通常ファイルのデータの格納には用いられず、 metadata だけに用いられますので、物理メモリーのほとんどを 仮想記憶システムに任せてしまった方が良いでしょう。デフォルトの バッファーキャッシュサイズはマシンのメモリー量に関わらず、 ほとんどの場合、最適となります。ブートメッセージ中の メモリー量を示している "using X buffers containing Y memory" は ファイルデータのキャッシュ用のメモリー量を示していませんので 数字が変わらなくても心配しないでください。

重要な変更点はより多くのメモリーを通常ファイルデータのキャッシュに 用いることができるということです。このためアクセスしようとした ファイルのデータがすでにメモリー中に存在することが多くなり、結果として ファイルシステムの入出力が速くなります。速くなる割合は何をするかにも よりますが、多くの場合その違いに気付くことができるでしょう。

以下も参照してください: Chuck Silvers の論文 UBC: An Efficient Unified I/O and Memory Caching Subsystem for NetBSD

さらなる読み物

NetBSD に特有のドキュメント (トップ)

その他のオンライン ドキュメント (トップ)

Back to  NetBSD ドキュメンテーション