vinum

Section: Devices and Network Interfaces (4)
索引 jman

BSD mandoc
FreeBSD  

索引

名称

vinum - 論理ボリュームマネージャ  

索引

書式

kldload vinum kldload Vinum  

索引

解説

は論理ボリュームマネージャです。Veritas Volume Manager に喚起されていますが 直接由来するものではありません。これは次のような機能を提供します。

 

索引

カーネルの設定

は現在カーネルロード可能モジュール (kld) として提供されており、 カーネルの設定は不要です。 他の kld と同様、kld は OS のバージョンと 絶対に適合する必要があります。そうでなければ はエラーメッセージを出力して終了するでしょう。

には現在 2 つのバージョンがあります。 それは、RAID-5 機能を持たない自由に入手可能なバージョンと、 RAID-5 の機能を持つ完全なバージョンです。完全なバージョンは Cybernet Systems Inc. (http://www.cybernet.com) から入手可能です。  

索引

VINUM の起動

通常、設定されたバージョンの をブート時に起動させます。 /etc/rc.conf 内の変数 vinum_drives に ドライブが置かれているスライスを設定します。例えば、 ドライブが /dev/da1h /dev/da2h /dev/da3h /dev/da4h /dev/da5h にあるとすると、この変数を次のように設定します。 
vinum_drives="/dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5"

 

索引

VINUM のインストール

自由に入手可能なバージョンの kld は /modules/vinum.ko であり、RAID-5 バージョンの kld は /modules/Vinum.o です。 モジュールをロードするには次のコマンドを実行します: 

# kldload vinum

また vinum(8) はロードされていなければ kld モジュールを自動的にロードします。

vinum をロードした後、設定を実行する必要があります。すでにインストールが 終わっていれば、次のコマンドにより、 存在するディスク集合から設定を読み出します。 

# vinum read /dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5 /dev/da6

このコマンドでは vinum により使われるすべてのデバイスを指定する必要があります。 vinum(8) は、最新の設定ファイルを使用して、 設定をデバイスより読み出します。 引き続いて、より古い設定から得られた追加情報があれば、設定を更新します。 このようなコマンドは通常、起動ファイル /etc/rc に埋めこまれています。

設定を作成する方法については vinum(8) を参照してください。

kld をアンロードするには、まず kldstat で Id フィールドを探します。 

# kldstat
Id Refs Address    Size     Name
 1    2 0xf0100000 1c7de8   kernel
 2    1 0xf0f5b000 b0000    Vinum.ko

モジュールをアンロードするには kldunload を使います: 

# kldunload -n Vinum

kld をアンロードできるのはアイドル中、言い替えると ボリュームがマウントされておらず、他の プログラムのインスタンスがアクティブでない時のみです。 kld のアンロードはボリューム内のデータを破壊しません。  

オブジェクトの設定と起動

オブジェクトの設定と起動には、 vinum(8) ユーティリティを使ってください。  

索引

IOCTL 呼び出し

ioctl 呼び出しは 設定プログラムだけが使うように設計されています。 ヘッダファイル /sys/sys/vinumio.h に説明があります。  

ディスクラベル

伝統的なディスク特殊デバイスは ディスクラベル をデバイスの第 2 セクタに持っています。 詳細については disklabel(5) を参照してください。 このディスクラベルにはデバイス内のパーティション情報が記述されています。 はボリュームをさらに分割することはないので、ボリュームには物理ディスクラベル がありません。 利便のため、 には ioctl 呼び出し DIOCGDINFO (ディスクラベルの取得), DIOCGPART (パーティション情報の取得), DIOCWDINFO (パーティション情報の書き込み), DIOCSDINFO (パーティション情報の設定) が実装されています。DIOCGDINFO と DIOCGPART は 内部的なディスクラベル情報を参照しますが、これはボリューム内には存在しません。 従って、 disklabel(8) の -r オプションは、生のディスク情報を読むので、失敗するでしょう。

一般に、 disklabel(8) は vinum ボリュームにとって有用な効果はありません。もし動作させると、 disklabel は 3 つのパーティション a, b, c を表示し、fstype を除いて これらは同じになるでしょう。例えば以下のように表示されます: 

3 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:     2048        0    4.2BSD     1024  8192     0   # (Cyl.    0 - 0)
  b:     2048        0      swap                        # (Cyl.    0 - 0)
  c:     2048        0    unused        0     0         # (Cyl.    0 - 0)

は DIOCWDINFO と DIOCSDINFO の ioctl を無視します。すなわち何も変更しません。 従って、ディスクラベルを変更しようとすると何の表示もなく無視されるでしょう。  

索引

ファイルシステムの作成

ボリュームはパーティションを持たないので、ボリュームの名前に関してディスク パーティションの名前付けの通常のルールに従う必要はありません。 物理ディスクパーティションにおいては、デバイス名の最後の文字は パーティション識別子 (a から h) を指定します。 ボリュームはこの規則に従う必要はありません。しかし従わなかった場合、 newfs がパーティションの識別が出来ないと文句を言うでしょう。この問題を解決するには newfs に対して -v フラグを指定してください。  

索引

オブジェクトの名前付け

はデフォルトの名前をプレックスとサブディスクに割り当てます。この名前を 上書きすることも可能です。しかしデフォルトの名前を上書きすることは推奨 しません。オブジェクトに任意の名前を付けられる Veritas(tm) volume manager の使用経験からすると、このような自由度に大きな利点はなく、 混乱を引き起こすでしょう。

名前には空白でない任意の文字を使えますが、英数字とアンダスコアのみに 制限することを勧めます。ボリューム、プレックス、サブディスクの名前には 64 文字まで、またドライブの名前には 32 文字まで使えます。 ボリュームとプレックスの名前を選ぶ時には、 自動的に生成されるプレックス名とサブボリューム名が、 これらの元となる名前よりも長くなることに注意してください。

使用例

オブジェクトが vinum(8) の設定ファイル例の節に説明されているものであるとします。 ディレクトリ /dev/vinum は次のように見えるでしょう: 

# ls -lR /dev/vinum/ /dev/rvinum
total 5
brwxr-xr--  1 root  wheel   25,   2 Mar 30 16:08 concat
brwx------  1 root  wheel   25, 0x40000000 Mar 30 16:08 control
drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 drive
drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 plex
drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 rvol
drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 sd
brwxr-xr--  1 root  wheel   25,   3 Mar 30 16:08 strcon
brwxr-xr--  1 root  wheel   25,   1 Mar 30 16:08 stripe
brwxr-xr--  1 root  wheel   25,   0 Mar 30 16:08 tinyvol
drwxrwxrwx  7 root  wheel       512 Mar 30 16:08 vol
brwxr-xr--  1 root  wheel   25,   4 Mar 30 16:08 vol5

/dev/vinum/drive:
total 0
brw-r-----  1 root  operator    4,  15 Oct 21 16:51 drive2
brw-r-----  1 root  operator    4,  31 Oct 21 16:51 drive4

/dev/vinum/plex:
total 0
brwxr-xr--  1 root  wheel   25, 0x10000002 Mar 30 16:08 concat.p0
brwxr-xr--  1 root  wheel   25, 0x10010002 Mar 30 16:08 concat.p1
brwxr-xr--  1 root  wheel   25, 0x10000003 Mar 30 16:08 strcon.p0
brwxr-xr--  1 root  wheel   25, 0x10010003 Mar 30 16:08 strcon.p1
brwxr-xr--  1 root  wheel   25, 0x10000001 Mar 30 16:08 stripe.p0
brwxr-xr--  1 root  wheel   25, 0x10000000 Mar 30 16:08 tinyvol.p0
brwxr-xr--  1 root  wheel   25, 0x10000004 Mar 30 16:08 vol5.p0
brwxr-xr--  1 root  wheel   25, 0x10010004 Mar 30 16:08 vol5.p1

/dev/vinum/rvol:
total 0
crwxr-xr--  1 root  wheel   91,   2 Mar 30 16:08 concat
crwxr-xr--  1 root  wheel   91,   3 Mar 30 16:08 strcon
crwxr-xr--  1 root  wheel   91,   1 Mar 30 16:08 stripe
crwxr-xr--  1 root  wheel   91,   0 Mar 30 16:08 tinyvol
crwxr-xr--  1 root  wheel   91,   4 Mar 30 16:08 vol5

/dev/vinum/sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20000002 Mar 30 16:08 concat.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100002 Mar 30 16:08 concat.p0.s1
brwxr-xr--  1 root  wheel   25, 0x20010002 Mar 30 16:08 concat.p1.s0
brwxr-xr--  1 root  wheel   25, 0x20000003 Mar 30 16:08 strcon.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100003 Mar 30 16:08 strcon.p0.s1
brwxr-xr--  1 root  wheel   25, 0x20010003 Mar 30 16:08 strcon.p1.s0
brwxr-xr--  1 root  wheel   25, 0x20110003 Mar 30 16:08 strcon.p1.s1
brwxr-xr--  1 root  wheel   25, 0x20000001 Mar 30 16:08 stripe.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100001 Mar 30 16:08 stripe.p0.s1
brwxr-xr--  1 root  wheel   25, 0x20000000 Mar 30 16:08 tinyvol.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100000 Mar 30 16:08 tinyvol.p0.s1
brwxr-xr--  1 root  wheel   25, 0x20000004 Mar 30 16:08 vol5.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100004 Mar 30 16:08 vol5.p0.s1
brwxr-xr--  1 root  wheel   25, 0x20010004 Mar 30 16:08 vol5.p1.s0
brwxr-xr--  1 root  wheel   25, 0x20110004 Mar 30 16:08 vol5.p1.s1

/dev/vinum/vol:
total 5
brwxr-xr--  1 root  wheel   25,   2 Mar 30 16:08 concat
drwxr-xr-x  4 root  wheel       512 Mar 30 16:08 concat.plex
brwxr-xr--  1 root  wheel   25,   3 Mar 30 16:08 strcon
drwxr-xr-x  4 root  wheel       512 Mar 30 16:08 strcon.plex
brwxr-xr--  1 root  wheel   25,   1 Mar 30 16:08 stripe
drwxr-xr-x  3 root  wheel       512 Mar 30 16:08 stripe.plex
brwxr-xr--  1 root  wheel   25,   0 Mar 30 16:08 tinyvol
drwxr-xr-x  3 root  wheel       512 Mar 30 16:08 tinyvol.plex
brwxr-xr--  1 root  wheel   25,   4 Mar 30 16:08 vol5
drwxr-xr-x  4 root  wheel       512 Mar 30 16:08 vol5.plex

/dev/vinum/vol/concat.plex:
total 2
brwxr-xr--  1 root  wheel   25, 0x10000002 Mar 30 16:08 concat.p0
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 concat.p0.sd
brwxr-xr--  1 root  wheel   25, 0x10010002 Mar 30 16:08 concat.p1
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 concat.p1.sd

/dev/vinum/vol/concat.plex/concat.p0.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20000002 Mar 30 16:08 concat.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100002 Mar 30 16:08 concat.p0.s1

/dev/vinum/vol/concat.plex/concat.p1.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20010002 Mar 30 16:08 concat.p1.s0

/dev/vinum/vol/strcon.plex:
total 2
brwxr-xr--  1 root  wheel   25, 0x10000003 Mar 30 16:08 strcon.p0
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 strcon.p0.sd
brwxr-xr--  1 root  wheel   25, 0x10010003 Mar 30 16:08 strcon.p1
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 strcon.p1.sd

/dev/vinum/vol/strcon.plex/strcon.p0.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20000003 Mar 30 16:08 strcon.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100003 Mar 30 16:08 strcon.p0.s1

/dev/vinum/vol/strcon.plex/strcon.p1.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20010003 Mar 30 16:08 strcon.p1.s0
brwxr-xr--  1 root  wheel   25, 0x20110003 Mar 30 16:08 strcon.p1.s1

/dev/vinum/vol/stripe.plex:
total 1
brwxr-xr--  1 root  wheel   25, 0x10000001 Mar 30 16:08 stripe.p0
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 stripe.p0.sd

/dev/vinum/vol/stripe.plex/stripe.p0.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20000001 Mar 30 16:08 stripe.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100001 Mar 30 16:08 stripe.p0.s1

/dev/vinum/vol/tinyvol.plex:
total 1
brwxr-xr--  1 root  wheel   25, 0x10000000 Mar 30 16:08 tinyvol.p0
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 tinyvol.p0.sd

/dev/vinum/vol/tinyvol.plex/tinyvol.p0.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20000000 Mar 30 16:08 tinyvol.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100000 Mar 30 16:08 tinyvol.p0.s1

/dev/vinum/vol/vol5.plex:
total 2
brwxr-xr--  1 root  wheel   25, 0x10000004 Mar 30 16:08 vol5.p0
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 vol5.p0.sd
brwxr-xr--  1 root  wheel   25, 0x10010004 Mar 30 16:08 vol5.p1
drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 vol5.p1.sd

/dev/vinum/vol/vol5.plex/vol5.p0.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20000004 Mar 30 16:08 vol5.p0.s0
brwxr-xr--  1 root  wheel   25, 0x20100004 Mar 30 16:08 vol5.p0.s1

/dev/vinum/vol/vol5.plex/vol5.p1.sd:
total 0
brwxr-xr--  1 root  wheel   25, 0x20010004 Mar 30 16:08 vol5.p1.s0
brwxr-xr--  1 root  wheel   25, 0x20110004 Mar 30 16:08 vol5.p1.s1

/dev/rvinum:
crwxr-xr--  1 root  wheel   91,   2 Mar 30 16:08 rconcat
crwxr-xr--  1 root  wheel   91,   3 Mar 30 16:08 rstrcon
crwxr-xr--  1 root  wheel   91,   1 Mar 30 16:08 rstripe
crwxr-xr--  1 root  wheel   91,   0 Mar 30 16:08 rtinyvol
crwxr-xr--  1 root  wheel   91,   4 Mar 30 16:08 rvol5

プレックスやサブディスクを分離した場合には、 この名前は予約されたままになります。 サブディスクはそれが配置されているディスクの名を元に名付けられ、 プレックスはサブディスクの名を元に名付けられています。 この対応付けにはまだ考慮の余地があります。  

オブジェクトの状態

各 オブジェクトには、オブジェクトに関連づけられた状態があります。 はオブジェクトに対する操作を決定するためにこの状態を利用します。

 

ボリュームの状態

ボリュームには次の状態がありえます。

volume_down
ボリュームが全くアクセス不能です。
volume_up
ボリュームは起動しており、少なくとも一部は機能しています。すべてのプレックス が利用可能とは限りません。

 

プレックスの状態

プレックスには次の状態がありえます。

faulty
プレックスは I/O エラーにより完全に停止しています。
down
プレックスは管理者により停止させられています。
initializing
プレックスは初期化中です。

以下の状態は、プレックスの少なくとも一部は起動していることを表します。

corrupt
プレックスエントリは少なくとも一部は起動しています。すべてのサブディスクが 利用可能ではなく、一貫性の欠如が起こっています。 もし壊れていない他のプレックスが なければ、ボリュームにはもはや一貫性がありません。
degraded
RAID-5 プレックスエントリはアクセス可能ですが、 1 つのサブディスクが停止しており、 多くの I/O 要求のためには修復が必要です。
flaky
プレックスは本当に起動していますが、復旧されたサブディスクを持っています。 このサブディスクは、完全に信じることのできない状態であり、 もし避けることが可能であれば読みたくない状態です。
up
プレックスエントリは完全に起動しています。 すべてのサブディスクが起動しています。

 

サブディスクの状態

サブディスクには次の状態がありえます。

empty
サブディスクエントリは完全に作成されました。すべてのフィールドは正常で、 ディスクは更新されていますが、ディスク上にデータはありません。
initializing
サブディスクエントリは完全に作成され、現在初期化中です。

以下の状態は、無効なデータを表します。

obsolete
サブディスクエントリは完全に作成されました。すべてのフィールドは正常で、 ディスク上の設定は更新され、データは有効ですが、ドライブが停止させられており、 その結果更新に失敗しています。
stale
サブディスクエントリは完全に作成されました。すべてのフィールドは正常で、 ディスクは更新され、データは有効ですが、ドライブが故障しており、 更新が失われています。

以下の状態は、有効だがアクセスできないデータを表します。

crashed
サブディスクエントリは完全に作成されました。すべてのフィールドは正常で、 ディスクは更新され、データは有効ですが、ドライブが停止しています。 故障の後サブディスクへの書き込みは行われておらず、そのためデータは有効です。
down
サブディスクエントリは起動しており、有効なデータを持ち、管理者により 停止させられています。データは有効です。
reviving
サブディスクは現在復活作業中です。書き込みは可能ですが、読み出しはできません。

以下の状態は、有効なデータを持つアクセス可能なサブディスクを表します。

reborn
サブディスクエントリは完全に作成されました。すべてのフィールドは正常で、 ディスクは更新され、データは有効ですが、 ドライブが停止した後再び起動した状態です。 更新は全く失われていませんが、サブディスクが損傷している可能性があります。 選択の余地があればこのサブディスクからの読み出しは行わないでしょう。 もしこのサブディスクがプレックス内で該当するアドレス空間をカバーする唯一の サブディスクだった場合、そのような状況下ではサブディスクの状態を up に設定 します。従ってこの状態は、読み出し要求を満たす他のサブディスクが存在することを 意味します。
up
サブディスクエントリは完全に作成されました。すべてのフィールドは正常で、 ディスクは更新され、データは有効です。

 

ドライブの状態

ドライブには次の状態がありえます。

down
ドライブはアクセス不能です。
up
ドライブは起動しており動作中です。

 

索引

バグと手抜かり

  1. は新しいプロダクトです。多くのバグがあるでしょう。 設定のメカニズムは必ずしも完全には動作していません。 もし困ったら、問題を報告する前に次の URL を参照してください。 http://www.lemis.com/vinum_beta.html および http://www.lemis.com/vinum_debugging.html
  2. モジュールを kldunload コマンドを使ってアンロードすることが可能です。しかしこの操作にはバグが多く、 この操作が存在する理由は単にシステムをテストする人がやりやすいようにするため です。代わりの方法はリブートです。 動作確率は約 80% です。 すなわちアンロードの 5 回に 1 回はパニックになると思われます。
  3. を静的にリンクしたカーネルを構築することもできますが、この方法は 全くテストされていません。もし、 擬似デバイスを静的リンクした状態で問題が起きた場合でも kld モジュール で問題が再現されない限り、わざわざ問題を報告しないで下さい。
  4. RAID-5 プレックスは初期化する必要があります。 初期化をしなくても、通常の運用の妨げにはなりませんが、 ディスクのうちの 1 つが故障した際に 全体の破壊を引き起こすでしょう。この初期化を強制するためのよい方法 (または低速だとしても、パリティブロックを再構築する代替方法) が思いつきません。 何かいいアイデアがあれば提供を歓迎します。
  5. カーネルと kld のバージョンの相違を検出する仕組みは実装されていません。

 

索引

VINUM に関する問題のデバッグ

に関する問題の解決は難しい事かもしれません。この節ではいくつかのアプローチ を紹介します。  

設定に関する問題

の設定は、比較的 (非常に) 問題にぶつかりやすいと言えます。 問題が起きたら、まず行うべきことは設定情報の 更新を次のようにして止めることです。 

# vinum setdaemon 4

これにより更新とディスク上の設定の更なる破壊を止めるでしょう。

次に、ディスク上の設定を確認します。Bourne タイプのシェルで次のようにします。 

# rm -f log
# for i in /dev/da0s1h /dev/da1s1h /dev/da2s1h /dev/da3s1h; do
>    (dd if=/dev/da1h skip=8 count=6|tr -d '\000-\011\200-\377'; echo) >> log
>  done

デバイスの名前は、すべての スライスの名前です。 そうすると、 log ファイルには次のような内容が入っているはずです。 

IN VINOpanic.lemis.comdrive1}6E7~^K6T^Yfoovolume obj state up
volume src state up
volume raid state down
volume r state down
volume foo state up
plex name obj.p0 state corrupt org concat vol obj
plex name obj.p1 state corrupt org striped 128b vol obj
plex name src.p0 state corrupt org striped 128b vol src
plex name src.p1 state up org concat vol src
plex name raid.p0 state faulty org disorg vol raid
plex name r.p0 state faulty org disorg vol r
plex name foo.p0 state up org concat vol foo
plex name foo.p1 state faulty org concat vol foo
sd name obj.p0.s0 drive drive2 plex obj.p0 state reborn len 409600b driveoffset 265b plexoffset 0b
sd name obj.p0.s1 drive drive4 plex obj.p0 state up len 409600b driveoffset 265b plexoffset 409600b
sd name obj.p1.s0 drive drive1 plex obj.p1 state up len 204800b driveoffset 265b plexoffset 0b
sd name obj.p1.s1 drive drive2 plex obj.p1 state reborn len 204800b driveoffset 409865b plexoffset 128b
sd name obj.p1.s2 drive drive3 plex obj.p1 state up len 204800b driveoffset 265b plexoffset 256b
sd name obj.p1.s3 drive drive4 plex obj.p1 state up len 204800b driveoffset 409865b plexoffset 384b

最初の行は ラベルを含んでおり、 IN VINO というテキストで始まっている必要があります。 この行にはシステムの名前も含まれています。正確な定義は /usr/src/sys/dev/vinum/vinumvar.h に記載されています。 保存された設定はこの行の途中から volume obj state up というテキストで始まっています。これはディスクのセクタ 9 から始まっています。 それ以降の出力はディスク上の設定の残りの部分を示しています。もしかすると すべての設定を見るためには、 dd コマンドの count の引数を増やす必要があるかもしれません。

すべてのディスク上の設定は同じであることが必要です。そうでない場合には、 log ファイルの正確な中身とともに問題を報告して下さい。 ディスク上の設定を回復するためにできることはおそらくほとんどないでしょうが、 もしオブジェクトを生成した時に使ったファイルのコピーを保存してあれば、 オブジェクトを再生成できるでしょう。 create コマンドはサブディスクのデータを変更しないので、このコマンドはデータの破壊を 引き起こしません。この種の問題に出会った場合には、 resetconfig コマンドを使う必要があるかもしれません。  

カーネルパニック

に由来すると思われるパニックを解析するには、 デバッグ用カーネルを構築する必要 があります。デバッグ用カーネルの構築の詳細については、オンラインハンドブック を参照してください。 カーネルロード可能モジュールのシンボル情報を得るには、更に作業が必要です。

  1. 可能であれば、デバッグカーネルのコピーまたはリンクを /var/crash/kernel.gdb に作成します。これは gdb の初期化ファイルがこの位置を検索するからです。
  2. モジュールをデバッグ情報とともに構築していることを確認しましょう。 通常の Makefile であれば、これはデフォルトの設定です。
  3. 開始後、次のコマンドを実行しましょう: 
    echo add-symbol-file /modules/vinum.ko \
  0x`objdump --section-headers /modules/vinum.ko \
  | grep ' .text' \
  | awk '{print $4}'`+`kldstat \
  | grep vinum | awk '{print $3}'`

    これをファイルに格納し、実行可能にし、実行するのが最も簡単です。 出力は次のようになるでしょう: 

    add-symbol-file /modules/vinum.ko 0x00005e24+0xf0f4e000
  4. /usr/src/sys/modules/vinum/.gdbinit.crash ファイルをあなたが解析を実行したいディレクトリ (例えば /var/crash ) にコピーし、 .gdbinit に名前を変えます。
  5. /modules に置いてあるバージョンの がシンボルを含んでいないと、エラーメッセージは表示されませんが、 スタックトレースはシンボルを表示しません。 gdb を始める前にモジュールをチェックしましょう。 
    $ file /modules/vinum.ko 
/modules/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, 
  version 1 (FreeBSD), not stripped

    その出力が /modules/vinum.ko is stripped だった場合、strip されていないバージョンを見つける必要が あります。通常、 /usr/obj/sys/modules/vinum/vinum.ko の中 ( make world を用いて を構築した場合) か /usr/src/sys/modules/vinum/vinum.ko の中 (このディレクトリで を構築した場合) にあります。

  6. もしデバッグカーネルを /var/crash/kernel.gdb という名前にしていない場合には、 .gdbinit を編集して、正しい場所を指し示すようにしてください。 シリアル接続を通してリモートデバッグをしている場合には、 /usr/src/sys/modules/vinum/.gdbinit.crash ファイルを .gdbinit という名前でデバッグを実行しているディレクトリにコピーして、 次のコマンドで起動してください。 
    gdb -k

    gdb は自動的に接続を確立します。リモートマシンはその時点で gdb が動作中でなければなりません。この .gdbinit ファイルはシリアル接続が 38400 bps で動作するものと期待しています。 別のスピードで動作させたい場合には、このファイルを適切に編集してください ( remotebaud に関する記述を探してください)。

  7. ダンプを取ったり gdb を使うことにより問題を分析してください。あるいは上記のシェルスクリプトの出力 を利用してください。次にリモートデバッグのセッションで vinum(8) における debug コマンドの利用例を示します。 
    (kgdb) add-symbol-file /usr/src/sys/modules/vinum/vinum.ko 0x00005e24+0xf0f4e000
add symbol table from file "/usr/src/sys/modules/vinum/vinum.ko" at text_addr = 0xf0f53e24?
(y or n) y
(kgdb) bt
#0  Debugger (msg=0xf0f661ac "vinum debug") at ../../i386/i386/db_interface.c:318
#1  0xf0f60a7c in vinumioctl (dev=0x40001900, cmd=0xc008464b, data=0xf6923ed0 "", 
      flag=0x3, p=0xf688e6c0) at 
      /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:109
#2  0xf01833b7 in spec_ioctl (ap=0xf6923e0c) at ../../miscfs/specfs/spec_vnops.c:424
#3  0xf0182cc9 in spec_vnoperate (ap=0xf6923e0c) at ../../miscfs/specfs/spec_vnops.c:129
#4  0xf01eb3c1 in ufs_vnoperatespec (ap=0xf6923e0c) at ../../ufs/ufs/ufs_vnops.c:2312
#5  0xf017dbb1 in vn_ioctl (fp=0xf1007ec0, com=0xc008464b, data=0xf6923ed0 "", 
      p=0xf688e6c0) at vnode_if.h:395
#6  0xf015dce0 in ioctl (p=0xf688e6c0, uap=0xf6923f84) at ../../kern/sys_generic.c:473
#7  0xf0214c0b in syscall (frame={tf_es = 0x27, tf_ds = 0x27, tf_edi = 0xefbfcff8, 
      tf_esi = 0x1, tf_ebp = 0xefbfcf90, tf_isp = 0xf6923fd4, tf_ebx = 0x2, 
      tf_edx = 0x804b614, tf_ecx = 0x8085d10, tf_eax = 0x36, tf_trapno = 0x7,
      tf_err = 0x2, tf_eip = 0x8060a34, tf_cs = 0x1f, tf_eflags = 0x286, 
      tf_esp = 0xefbfcf78, tf_ss = 0x27}) at ../../i386/i386/trap.c:1100
#8  0xf020a1fc in Xint0x80_syscall ()
#9  0x804832d in ?? ()
#10 0x80482ad in ?? ()
#11 0x80480e9 in ?? ()
(kgdb) f 1
#1  0xf0f60a7c in vinumioctl (dev=0x40001900, cmd=0xc008464b, data=0xf6923ed0 "",
    flag=0x3, p=0xf688e6c0) at
    /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:109
Source file is more recent than executable.
109             Debugger ("vinum debug");

    デバッガから実行開始する時、フレーム 1 のソース (上の例では最後の部分) に次の 文字列が含まれていることは重要です。 

    Debugger ("vinum debug");

    これはアドレス定義が正しいことを示しています。

最初の調査で最も重要な情報は、上に示されているように bt (バックトレース) コマンドの出力です。  

索引

作者

Greg Lehey <grog@lemis.com>  

索引

歴史

vinum は FreeBSD 3.0 から登場しました。  

索引

関連項目

vinum(8), disklabel(5), disklabel(8)

 

索引

Index

名称
書式
解説
カーネルの設定
VINUM の起動
VINUM のインストール
オブジェクトの設定と起動
IOCTL 呼び出し
ディスクラベル
ファイルシステムの作成
オブジェクトの名前付け
オブジェクトの状態
ボリュームの状態
プレックスの状態
サブディスクの状態
ドライブの状態
バグと手抜かり
VINUM に関する問題のデバッグ
設定に関する問題
カーネルパニック
作者
歴史
関連項目

jman


Time: 07:07:25 GMT, January 12, 2009