vinum(4)

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

kldload vinum

kldload Vinum

解説

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

• ボリュームは 1 つ以上のプレックスから構成されます。各プレックスはボ リュームの全アドレス空間を持ちます。これは RAID-1 (ミラー) の実装を表 します。複数のプレックスを使うことにより以下のような効果があります。

• 読み出しスループットの向上。 vinum は最もアクセスの少ないディスク からデータを読み出すので、複数のディスクからなるプレックスを持つ ボリュームならより多くのデータを並列に読み出すことが可能です。 vinum は 1 プレックスからのみデータを読み出しますが、すべてのプ レックスに対してデータを書き込みます。

• 信頼性の向上。異なるディスク上の複数のプレックスに格納することに より、プレックスのうちの 1 つが利用不能になったとしてもデータを取 り出せるでしょう。 RAID-5 プレックス (下記参照) と比べて、複数の プレックスはより多くのストレージ領域を必要としますが、パフォーマ ンスが優れています。特にドライブ故障の際の差は顕著でしょう。

• 冗長なプレックスを利用して、オンラインのままデータ再構成ができま す。あるプレックスを結合し、続いて古いプレックスの 1 つを分離する ことにより、アクセスを妨げることなくオンラインでデータを移動でき ます。

• 冗長なプレックスにより、一貫性を持ったファイルシステムダンプを得 ることができます。プレックスを結合し、ある時点で分離することによ り、分離されたプレックスは分離した時点におけるファイルシステムの 正確なスナップショットになります。

• 各プレックスは、サブディスクと呼ばれる、 1 つ以上の論理ディスクスライ スから構成されます。サブディスクは物理ディスクの連続したブロックとし て定義されます。プレックスはあらゆる適切な数のサブディスクで構成でき ます。(言い替えれば、本当の制限はサブディスクの数ではなく別の要因、多 くのサブディスクの管理に関するメモリやパフォーマンスといったものです)

• サブディスクとプレックスの間の編成にはいくつかの種類があります:

• コンカチネート化プレックスは 1 つ以上のサブディスクからなり、各サ ブディスクはプレックスのアドレス空間の中で連続した部分として編成 されます。

• ストライプ化プレックスは 2 つ以上の、大きさの等しいサブディスクか らなります。ファイルのアドレス空間はストライプに、すなわちサブ ディスクの大きさの整数分の 1 に、対応付けられます。連続したプレッ クスアドレス空間には、各サブディスクのストライプが順番に対応付け られます。ストライプ化プレックスのサブディスクはすべて同じ大きさ である必要があります。

• RAID-5 プレックスには大きさの等しいサブディスクが、少なくとも 3 つは必要です。これはストライプ化プレックスに似ていますが、各スト ライプの中で 1 つのサブディスクがパリティ情報を持っている点が異な ります。パリティ情報を持つサブディスクはストライプによって異なり ます。1 番目のストライプでは 1 番目のサブディスク、 2 番目のスト ライプでは 2 番目のサブディスクといったようになります。単一ディス ク故障の場合、 vinum は残りのサブディスクに格納されている情報から データを復元します。この編成は読み出しが集中するアクセスに特に向 いています。RAID-5 プレックスのサブディスクはすべて同じ大きさであ る必要があります。

• ドライブはストレージ階層の中で最も低レベルなものです。これはディスク 特殊デバイスを表します。

• vinum は自動起動機能を提供します。通常の UNIX ファイルシステムと異な り、 vinum ボリューム内にすべての設定情報を持っているため、サブシステ ムが利用可能になった時に正しく起動することを保証できます。この点が Veritas™ File System に対する重要な利点でもあります。この機能はボ リュームの存在を検出します。これは、ボリュームを自動的にマウントする という意味ではありません。マウントを実行するのは、通常の /etc/fstab による起動手順です。

カーネルの設定

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

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

通常、設定されたバージョンの vinum をブート時に起動させます。 /etc/rc.conf 内の変数 vinum_drives に vinum ドライブが置かれているスライ スを設定します。例えば、 vinum ドライブが /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 設定を作成する方法については 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 をアンロードできるのはアイドル中、言い替えるとボリュームがマウントさ れておらず、他の vinum プログラムのインスタンスがアクティブでない時のみで す。 kld のアンロードはボリューム内のデータを破壊しません。

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

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

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

ディスクラベル

伝統的なディスク特殊デバイスは ディスクラベルをデバイスの第 2 セクタに 持っています。詳細については disklabel(5) を参照してください。このディス クラベルにはデバイス内のパーティション情報が記述されています。 vinum はボ リュームをさらに分割することはないので、ボリュームには物理ディスクラベル がありません。利便のため、 vinum には 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)

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

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

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

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

• UNIX ドライブと異なり、 vinum ボリュームをパーティションへとさらに分 割しません。従ってディスクラベルを持ちません。不幸な事に、このことに よっていくつかのユーティリティ、特に newfs は混乱します。 newfs は通 常 vinum ボリューム名の最後の文字をパーティション識別子として解釈しよ うとするからです。 a から c の文字で終わらない文字列をボリューム名に 使った場合には、 newfs に対して −v フラグを指定してこの規則を無視する よう newfs に指示することが必要です。

• プレックスには明示的に名前を割り当てる必要はありません。デフォルトの プレックス名はボリューム名に文字列 .p とプレックスの番号を続けたもの です。例えば、ボリューム vol3 のプレックスは vol3.p0, vol3.p1 といっ た風に名付けられます。この名前を上書きすることは可能ですがお勧めしま せん。

• プレックスと同様、サブディスクについても自動的に名前が割り当てられ、 明示的な名前付けはお勧めしません。サブディスク名はプレックス名に文字 列 .s とサブディスクを識別する番号を続けたものです。例えば、プレック ス vol3.p0 のサブディスクは vol3.p0.s0, vol3.p0.s1 といった風に名付け られます。

• 一方、 ドライブは必ず名前を付ける必要があります。これにより、ドライブ を異なる場所に移動したとしても自動的に認識することが可能になります。 ドライブ名の長さは 32 文字までです。

使用例

vinum オブジェクトが 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

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

オブジェクトの状態

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

ボリュームの状態

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

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 ドライブは起動しており動作中です。

バグと手抜かり

2. vinum モジュールを kldunload コマンドを使ってアンロードすることが可 能です。しかしこの操作にはバグが多く、この操作が存在する理由は単にシ ステムをテストする人がやりやすいようにするためです。代わりの方法はリ ブートです。動作確率は約 80% です。すなわちアンロードの 5 回に 1 回 はパニックになると思われます。

3. vinum を静的にリンクしたカーネルを構築することもできますが、この方法 は全くテストされていません。もし、 vinum 擬似デバイスを静的リンクし た状態で問題が起きた場合でも kld モジュールで問題が再現されない限 り、わざわざ問題を報告しないで下さい。

4. RAID-5 プレックスは初期化する必要があります。初期化をしなくても、通 常の運用の妨げにはなりませんが、ディスクのうちの 1 つが故障した際に 全体の破壊を引き起こすでしょう。この初期化を強制するためのよい方法 ( または低速だとしても、パリティブロックを再構築する代替方法) が思いつ きません。何かいいアイデアがあれば提供を歓迎します。

5. カーネルと kld のバージョンの相違を検出する仕組みは実装されていませ ん。

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

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

設定に関する問題

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

デバイスの名前は、すべての vinum スライスの名前です。そうすると、 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

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

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

カーネルパニック

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

2. vinum モジュールをデバッグ情報とともに構築していることを確認しましょ う。通常の Makefile であれば、これはデフォルトの設定です。

3. vinum 開始後、次のコマンドを実行しましょう:

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

5. /modules に置いてあるバージョンの vinum がシンボルを含んでいないと、 エラーメッセージは表示されませんが、スタックトレースはシンボルを表示 しません。 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 を用いて vinum を構築した場合) か /usr/src/sys/modules/vinum/vinum.ko の中 (この ディレクトリで vinum を構築した場合) にあります。

gdb -k

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

(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)

FreeBSD 22 July 1998 FreeBSD