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 の起動
通常、設定されたバージョンの 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 のインストール
自由に入手可能なバージョンの 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 呼び出し
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 文字まで使えます。 ボリュームとプレックスの名前を選ぶ時には、 自動的に生成されるプレックス名とサブボリューム名が、 これらの元となる名前よりも長くなることに注意してください。

•   vinum(8) がオブジェクトを生成または削除すると、ディレクトリ /dev/vinum を作成し、その中に vinum が検出した各ボリュームに対応する デバイスエントリを作成します。また、vinum はサブディレクトリ /dev/vinum/plex と /dev/vinum/sd を作成し、その中にプレックスとサブディスクに対応するデバイスエントリを 格納します。更に、vinum は2つのディレクトリ /dev/vinum/vol と /dev/vinum/drive を作成し、その中にボリュームとドライブに対する階層的な情報を格納します。

•   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_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.  vinum は新しいプロダクトです。多くのバグがあるでしょう。 設定のメカニズムは必ずしも完全には動作していません。 もし困ったら、問題を報告する前に次の URL を参照してください。 http://www.lemis.com/vinum_beta.html および http://www.lemis.com/vinum_debugging.html

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 カーネルロード可能モジュールのシンボル情報を得るには、更に作業が必要です。

1.  可能であれば、デバッグカーネルのコピーまたはリンクを /var/crash/kernel.gdb に作成します。これは gdb の初期化ファイルがこの位置を検索するからです。

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

4.  /usr/src/sys/modules/vinum/.gdbinit.crash ファイルをあなたが解析を実行したいディレクトリ (例えば /var/crash ) にコピーし、 .gdbinit に名前を変えます。

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 を構築した場合) にあります。

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)