RAIDCTL(8)

名称
raidctl - RAIDframe ディスクドライバ用コンフィギュレーションユーティリティ

書式
-a component dev -B dev -c config_file dev -C config_file dev -f component dev -F component dev -g component dev -i dev -I serial_number dev -r component dev -R component dev -s dev -S dev -u dev

解説
は、RAIDframe ディスクデバイスである raid(4) 用の、ユーザレベルの制御プログラムです。 の主な使用目的は、RAIDframe ディスクデバイスを動的に configure したり unconfigure したりすることです。 RAIDframe ディスクデバイスに関する詳細は raid(4) を参照してください。

このドキュメントは、読者が少なくとも RAID や RAID のコンセプトに関する 基礎知識を持っていることを想定しています。

raidctl のコマンドラインオプションは以下の通りです:

-a component dev
    component をデバイス dev 用の hot spare として追加します。

-B dev
    スペアディスクからオリジナルディスクへ、再構築データのコピーバックを 開始します。これは、コンポーネントが故障し、その故障したドライブの データがスペアディスクに再構築された後で行われます。

-c config_file dev
    config_file で与えられたコンフィギュレーション情報にしたがって、RAIDframe デバイス dev を configure します。 config_file の内容に関する解説はこの後で出てきます。

-C config_file dev
    -c に似ていますが、強制的にコンフィギュレーションを行います。これは RAID セットを新規に configure する場合に必要です。

-f component dev
    これは、指定した component が failed になったとマークしますが、そのコンポーネントの再構築は開始させ ません。

-F component dev
    そのデバイスの component が failed になったとマークし、直ちにそのコンポーネントの再構築を開始します。 再構築データは hot spare 上に作られます。 これは、コンポーネントにハードウェア的故障がある場合に再構築処理を 開始させる場合に使うメカニズムのうちの 1 つです。

-g component dev
    指定したコンポーネントのコンポーネントラベルを取得します。

-i dev
    デバイス上のパリティを初期化(書き直し)します。これは、RAID デバイスに ラベルを書いた後でかつその RAID デバイス上にファイルシステムを作成する前に 行わなければ なりません。 また、通常はシステムがクラッシュした後 (かつ fsck(8) する前) に、パリティの正しさを保証するために使用しなければなりません。

-I serial_number dev
    デバイスの各コンポーネント上のコンポーネントラベルを初期化します。 serial_number は、 コンポーネントのどのセットが同じ RAID セットになるかを表すキーのうちの 1 つとして使われます。 強制しない限り、異なる RAID セットには異なったシリアル番号が使われます。

-r component dev
    利用可能なスペアコンポーネントのセットから、 component で指定したスペアディスクを取り除きます。

-R component dev
    必要であれば、指定した component を fail にし、 component を復活させるための再構築を直ちに開始します。 これは、コンポーネントにハードウェア的故障がある場合に再構築処理を 開始させるためのもう 1 つの手段です。

-s dev
    その RAIDframe デバイスの、各コンポーネントと spare のステータスを表示します。

-S dev
    コンポーネントの再構築の状態をチェックします。 failed になったデバイスの再構築がどれだけ進行しているかが出力されます。

-u dev
    その RAIDframe デバイスを unconfigure します。

raidctl が使用するデバイスは dev で指定します。 dev は、デバイスのフルネーム (たとえば i386 アーキテクチャであれば /dev/rraid0d, 他のアーキテクチャであれば /dev/rraid0c) で指定しても、 単に raid0 などとしても構いません。

コンフィギュレーションファイルのフォーマットは複雑なので、 ここでは簡単にしか説明しません。コンフィギュレーションファイル中では、 ‘#’ はコメントの開始を表します。

コンフィギュレーションファイルには 4 つの必須セクションと、2 つの省略可能部分 からなります。 各セクションは ‘START’ で始まり、セクション名、そのセクションに関連する コンフィギュレーションパラメータの順で続きます。 最初のセクションは ‘array’ セクションで、その RAID セット内の行、列、spare ディスクの数を指定します。 例えば:

    START array
    1 3 0

は、1 行、3 列、spare ディスクなしを表します。 複数次元のアレイを指定できますが、このドライバではさぽーとして いない ので注意してください。

2 番目のセクションは ‘disks’ セクションで、そのデバイスの実際のコンポーネントを指定します。たとえば:

    START disks
    /dev/sd0e
    /dev/sd1e
    /dev/sd2e

は、この 3 つのコンポーネントディスクが、その RAID デバイスで使用される ことを示しています。RAID デバイスを configure する時に、指定したドライブが 見つからなかった場合には、そのドライブは ‘failed’ であるとマークされ、そのシステムは degraded モードで動作します。 RAID デバイスのコンフィギュレーション中に、コンフィギュレーションファイル内の コンポーネントの順番が変化しないということが 必須 であるという点に注意してください。コンポーネントの順番を変えると、 その結果、(少なくとも書込み時に) データの喪失が起こります。

次のセクションは ‘spare’ セクションです。これは省略可能で、もしあれば、そのデバイスを ‘hot spares’ として使うことを表します。このデバイスはオンラインですが、 メインのコンポーネントのどれかが fail にならない限り RAID ドライバによって アクティブに使用されるということはありません。 簡単な例として、spare ディスクが 1 個のコンフィギュレーションの場合での ‘spare’ セクションは、以下のようになります:

    START spare
    /dev/sd3e

spare ドライブを使わないコンフィギュレーションの場合、 ‘spare’ セクションは省きます。

次のセクションは ‘layout’ セクションです。このセクションは、その RAID デバイスの レイアウトの概要に関するパラメータを表し、 1 ストライプユニットあたりのセクタ数、 1 パリティユニットあたりのストライプユニット数、 1 再構築ユニットあたりのストライプユニット数、 パリティコンフィギュレーションなどの情報を提供します。 このセクションは以下のようなものになります:

    START layout
    # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level
    32 1 1 5

ストライプユニットあたりのセクタ数はブロック数で書き、 インターリーブファクタを表します。つまり、単一ストライプごとに、 各コンポーネントで連続して書かれるセクタの数です。 この値に関して、適切な値を選択するという問題は、 RAID アーキテクチャにおける重要な問題です。 パリティユニットあたりのストライプユニット数と 再構築ユニットあたりのストライプユニット数は、通常はそれぞれ 1 をセットします。 1 より大きな値は許されますが、正しい値や、1 以外の値を指定した場合の結果 に関する議論はこのドキュメントの対象外です。 このセクションの最後の値は (この例では 5)、 希望するパリティコンフィギュレーションを表します。正しい値は以下のうちの いずれかです:

0   RAID レベル 0 です。パリティなしで、単純なストライピングだけです。

1   RAID レベル 1 です。ミラーリングです。

4   RAID レベル 4 です。コンポーネントを跨いだストライピングを行い、 最後のコンポーネントにパリティを保存します。

5   RAID レベル 5 です。コンポーネントを跨いだストライピングを行い、 パリティを全てのコンポーネントに分散させます。

この部分の正しいエントリは他にもあり、たとえば奇数-偶数パリティ、 RAID レベル 5 で rotated sparing、Chained declustering、 Interleaved declustering などがありますが、 これらのパリティ操作の現在のコードは NetBSD ではテストされていません。

次の必須セクションは ‘queue’ セクションです。ほとんどの場合、以下のように指定されます:

    START queue
    fifo 1

この例では、キューイング方法は fifo (first-in, first-out) と指定され、 各コンポーネントごとのキューのサイズが 1 リクエストに制限されます。 ここでの値 1 はかなり保守的ですが、ドライバのパフォーマンスを上げる には 100 またはそれ以上の値を使ったほうがいいかもしれません。 他のキューイング方法も指定できますが、それに関する議論は このドキュメントの対象外です。

最後のセクションは ‘debug’ セクションで、これは省略可能です。詳細は 歴史 のセクションで触れている RAIDframe のドキュメントを参照してください。 コンフィギュレーションファイルの詳細な例は、 使用例 のセクションを参照してください。

使用例
このセクションでの例は、 RAID 5 のコンフィギュレーションに焦点をあてます。 他の RAID コンフィギュレーションも、似たようなものになります。 RAID ドライバを実際のファイルシステムに適用する前に、 システム管理者は の 全ての オプションを使用して、コンポーネントの再構築プロセスがどう働くかを 理解しておくことを強く推めます。 この例はチュートリアルとして作ってはいませんが、ここで示すステップは、 任意の個数のディスクから同じサイズのパーティションを 4 個用意した 場合 (4 個全てのパーティションが 1 つのディスクである場合も含む) でも全く同じです。

の主目的は、 raid(4) デバイスの configure と unconfigure にあります。 デバイスを configure するには、まずはじめに以下のような コンフィギュレーションファイルを作ります:

    START array
    # numRow numCol numSpare
    1 3 1
    START disks
    /dev/sd1e
    /dev/sd2e
    /dev/sd3e
    START spare
    /dev/sd4e
    START layout
    # sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_5
    32 1 1 5
    START queue
    fifo 100

簡単に言うと、このコンフィギュレーションファイルは /dev/sd1e, /dev/sd2e, /dev/sd3e のコンポーネントによる RAID 5 コンフィギュレーションを示しており、 3 個のメインドライブのいずれか 1 個が fail した場合には /dev/sd4e を ‘hot spare’ として利用します。 上記のコンフィギュレーションが ‘rfconfig’ という名前のファイルに書かれているとすると、 通常、raid デバイス 0 は以下のようにして configure します:

    raidctl -c rfconfig raid0

上の例は、i386 アーキテクチャでは以下のものと同じです:

    raidctl -c rfconfig /dev/rraid0d

他の全てのアーキテクチャでは、/dev/rraid0d の部分が /dev/rraid0c になります。

コンポーネントラベルが正しくない場合、その RAID セットは -c では configure されません。 ‘コンポーネントラベル’ には、ユーザが指定したシリアル番号、そのコンポーネントの RAID セット内における row と column, そのコンポーネント上のデータ (およびパリティ) が ‘clean’ かどうかという、そのコンポーネントに関する重要な情報が含まれています。 コンポーネントラベルに関する詳細は raid(4) を参照してください。

新しい RAID セットには正しいコンポーネントラベルがないので、 RAID セットの最初のコンフィギュレーションには -c の代りに -C を使わなければなりません。

    raidctl -C rfconfig raid0

-C は、たとえコンポーネントラベルが正しくなくとも、コンフィギュレーションを 成功させます。このオプションは最初のコンフィギュレーション時以外に 軽々しく使ってはいけません。システムが RAID セットの configure を拒絶する場合には、これは正当な理由になるでしょう。

RAID セットが初めて configure された時、コンポーネントラベルの初期化と その RAID セット上のパリティの初期化をする必要があります。 コンポーネントラベルの初期化は以下のようにして行え:

    raidctl -I 112341 raid0

ここで ‘112341’ はその RAID セット用のユーザ指定のシリアル番号です。 全ての RAID セットに同じシリアル番号を使うと、 コンポーネントラベルのチェック機能の有用性が減るだけなので、 異なる RAID セット間では異なるシリアル番号を使うことを強く奨めます。

RAID セット上のパリティを初期化するには以下のようにします:

    raidctl -i raid0

この方法によるパリティの初期化は、きちんとシャットダウンしなかった後でも 必要になります。いったんパリティが正しいとわかれば、以降は そのデバイスやファイルシステムに disklabel(8), newfs(8), fsck(8) をすることができ、それからそのファイルシステムを使うためにマウントできます。

RAID セットが何をしているかを見るためには、以下のコマンドでステータスを 表示させます:

    raidctl -s raid0

出力は以下のよういになります:

    Components:
               /dev/sd1e: optimal
               /dev/sd2e: optimal
               /dev/sd3e: optimal
    Spares:
               /dev/sd4e: spare

これは、その RAID セットが問題のない状態にあることを表しています。

もしこれがこの RAID アレイを configure してから最初のものであるか、 そのシステムが前回きちんとシャットダウンしなかった状態でのブートの場合、 パリティの値が正しいことを確実にする必要があります。 これは、以下のようにして行います:

    raidctl -r raid0

いったんこれを行えば、その後はそのデバイスやファイルシステムに対して安全に disklabel(8) や newfs(8) や fsck(8) が行えます。

もし何らかの理由 (たぶん再構築のテスト) で、ドライブが fail したと 偽る必要がある場合、これは以下のようにすればできます:

    raidctl -f /dev/sd2e raid0

この後、そのシステムは全ての動作が degraded モードで行われ、 失われたデータは既存のデータとパリティから再計算されます。 この場合、raid0 のステータスは以下のようになります:

    Components:
               /dev/sd1e: optimal
               /dev/sd2e: failed
               /dev/sd3e: optimal
    Spares:
               /dev/sd4e [0][0]: spare

-f を使った場合には再構築が開始されないという点に注意してください。 ディスクを fail させてかつ再構築も開始させたい場合には -F オプションを使うべきです (もし必要であれば、はじめに -f オプションを使い、それから同じディスクに -F オプションを使っても構いません)。 再構築を開始した直後から、ステータスは以下のようになります:

    Components:
               /dev/sd1e: optimal
               /dev/sd2e: reconstructing
               /dev/sd3e: optimal
    Spares:
               /dev/sd4e [0][0]: used_spare

これは、再構築が進行中であることを表しています。再構築がどれだけ進行しているか を知るには、 -R オプションを使います。 これは、再構築がどこまえd完了したかをパーセンテージで表示します。 再構築が完了すると、 -s オプションでは以下のように表示されます:

    Components:
               /dev/sd1e: optimal
               /dev/sd2e: spared
               /dev/sd3e: optimal
    Spares:
               /dev/sd4e [0][0]: used_spare

ここで、少なくとも 2 つの選択肢があります。1 つは、もし /dev/sd2e が good であるとわかっている (つまり、fail になったのが -f や -F によるものか、fail になったディスクを交換した) ならば、 -C オプションでデータのコピーバックを開始できます。この場合、 /dev/sd4e の内容全体を /dev/sd2e にコピーすることになります。 コピーバック作業が完了すると、そのデバイスのステータスは以下のように なり:

    Components:
               /dev/sd1e: optimal
               /dev/sd2e: optimal
               /dev/sd3e: optimal
    Spares:
               /dev/sd4e [0][0]: spare

システムは通常動作に戻ります。

再構築後の第 2 の選択肢は、コンフィギュレーションファイル内の /dev/sd2e の部分を単に /dev/sd4e にするだけというものです。 たとえば、コンフィギュレーションファイルは以下のようになるはずです:

    START array
    1 3 0
    START drives
    /dev/sd1e
    /dev/sd4e
    /dev/sd3e

これは、/dev/sd4e と /dev/sd2e が完全に交換可能なのでできます。 コンフィギュレーション時にドライブの順番を変える場合には、できる限りの 注意を払ってください。 これは、データの紛失なしにデバイスまたはその順番を変える方法の 1 つです。 一般に、コンフィギュレーションファイル内のコンポーネントの順番は、 決して 変えるべきではありません。

raidctl で行う最後の操作は raid(4) デバイスの unconfigure です。これは、単に:

    raidctl -u raid0

とするだけででき、この時点でそのデバイスは再度 configure できるように なります。

警告
いくつかの RAID レベル (1, 4, 5, 6 やその他) は コンポーネントの故障によるある種のデータ損失を保護できます。 しかしながら、RAID 4 または RAID 5 システム上の 2 個のコンポーネントで 損失が起こったり、RAID 0 システム上の 1 個のコンポーネントで損失が起こった 場合には、ファイルシステム全体が損失します。 RAID は、習慣的なよいバックアップの代りには なりません。

パリティの再計算は、ディスクに障害が起こった場合には常に実行しなければ なりません。 これには、システムのクラッシュや、RAID デバイスを使いはじめる時も含まれます。 パリティを正しい状態に維持できないと壊滅的な状態になり、コンポーネントが 常に fail するはずです。パリティを正しく保たないのであれば、 パリティを使うよりは、RAID 0 を使ってディスクスペースと速度を稼いだ ほうがよいです。少なくとも、RAID 0 ではデータのセキュリティは向上しません。

関連ファイル
/dev/{,r}raid*
    raidctl のデバイススペシャルファイル。

関連項目
raid(4), ccd(4), rc(8)

歴史
RAIDframe は RAID の機構を rapid prototyping するためのフレームワーク として、Carnegie Mellon University (CMU) の Parallel Data Laboratory の人々によって開発されました。 RAIDframe の内部構造と機能に関する完全な解説は Carnegie Mellon University の Parallel Data Laboratory の William V. Courtright II, Garth Gibson, Mark Holland, LeAnn Neal Reilly, Jim Zelenka によって書かれた "RAIDframe: A Rapid Prototyping Tool for RAID Systems" の論文に書かれています。

raidctl コマンドが最初に登場したのは、CMU の RAIDframe v1.1 ディストリビューション内の プログラムのうちの 1 つとしてでした。 このバージョンの raidctl は完全に書き直されたもので、 NetBSD 1.4 で初めて登場しました。

著作権

    RAIDframe の著作権は以下の通りです:
    Copyright (c) 1994-1996 Carnegie-Mellon University.
    All rights reserved.
    Permission to use, copy, modify and distribute this software and
    its documentation is hereby granted, provided that both the copyright
    notice and this permission notice appear in all copies of the
    software, derivative works or modified versions, and any portions
    thereof, and that both notices appear in supporting documentation.
    CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
    CONDITION.  CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND
    FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
    Carnegie Mellon requests users of this software to return to
     Software Distribution Coordinator  or  Software.Distribution@CS.CMU.EDU
     School of Computer Science
     Carnegie Mellon University
     Pittsburgh PA 15213-3890
    any improvements or extensions that they make and grant Carnegie the
    rights to redistribute these changes.