Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
付録A デバイスマッパー
デバイスマッパーとは、ボリューム管理用のフレームワークを提供するカーネルドライバーです。これは論理ボリュームとして使用可能な、マップされたデバイスを作成する一般的な方法を提供します。デバイスマッパーは、ボリュームグループやメタデータ形式をとくに認識する訳ではありません。
デバイスマッパーは多くの高度な技術のための土台を提供します。LVM のほかにも、デバイスマッパーマルチパスと
dmraid コマンドがデバイスマッパーを使用します。デバイスマッパーに対するアプリケーションインターフェースは ioctl システムコールになり、ユーザーインターフェースは dmsetup コマンドになります。
LVM 論理ボリュームは、デバイスマッパーを使用してアクティブ化されます。それぞれの論理ボリュームは、マップされたデバイスに変換され、それぞれのセグメントが、そのデバイスを記述するマッピングテーブル内の行に変換されます。デバイスマッパーはリニアマッピング、ストライプ化マッピング、およびエラーマッピングを含む各種のマッピングターゲットをサポートします。2 つのディスクは、各ディスクに対して 1 つのリニアマッピングが指定される一対のリニアマッピングを維持することで 1 つの論理ボリュームとして連結することができます。LVM2 がボリュームを作成する場合、
dmsetup コマンドでクエリー可能な、配下のデバイスマッパーデバイスを作成します。マッピングテーブルのデバイスの形式に関する情報は、「デバイステーブルのマッピング」 を参照してください。デバイスをクエリーするための dmsetup コマンドの使用方法についての情報は、「dmsetup コマンド」 を参照してください。
A.1. デバイステーブルのマッピング
マップされたデバイスは、サポートされているデバイステーブルのマッピングを使用してデバイスの論理セクターの各範囲をマップする方法を指定するテーブルによって定義されます。マップされたデバイスのテーブルは以下の形式の行の一覧から作成されます。
start length mapping[mapping_parameters...]
デバイスマッパーテーブルの最初の行では、
start パラメーターはゼロ (0) でなければなりません。1 行にある start + length のパラメーター群は、次の行の start と同じでなければなりません。マッピングテーブルの行に指定されるマッピングパラメーターの種類は、その行に指定される mapping のタイプによって決まります。
デバイスマッパー内のサイズは常にセクターで指定されます (512 バイト)。
1 つのデバイスがデバイスマッパー内でマッピングパラメーターとして指定される場合、そのデバイスはファイルシステム内のデバイス名で参照されるか (例:
/dev/hda)、または major:minor の形式でメジャー番号とマイナー番号で参照されます。major:minor の形式は、パス名ルックアップを回避するので推奨されます。
デバイスのマッピングテーブルの例を以下に示します。このテーブルには 4 つのリニアターゲットがあります。
0 35258368 linear 8:48 65920 35258368 35258368 linear 8:32 65920 70516736 17694720 linear 8:16 17694976 88211456 17694720 linear 8:16 256
各行の最初の 2 つのパラメーターはセグメントの始点ブロックとセグメントの長さです。次のキーワードはマッピングターゲットであり、この例ではすべて
linear になっています。行のその他の部分は linear ターゲットのパラメーターで構成されています。
以下のサブセクションでは次のマッピングの形式について説明します。
- linear
- striped
- mirror
- snapshot および snapshot-origin
- error
- zero
- multipath
- crypt
- device-mapper RAID
- thin
- thin-pool
A.1.1. リニアマッピングターゲット
リニアマッピングターゲットは連続範囲のブロックを別のブロックデバイスにマップします。リニアターゲットの形式は以下のようになります。
start lengthlineardevice offset
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
device- ブロックデバイス。ファイルシステム内のデバイス名で参照されるか、または
major:minor形式のメジャー番号とマイナー番号で参照されます。 offset- デバイス上のマッピングの始点オフセット
以下の例は、仮想デバイスの始点ブロックが 0 、セグメントの長さが 1638400、メジャー/ マイナー番号ペアが 8:2、デバイスの始点オフセットが 41146992 であるリニアターゲットを示しています。
0 16384000 linear 8:2 41156992
以下の例は、デバイスパラメーターがデバイス
/dev/hda として指定されたリニアターゲットを示しています。
0 20971520 linear /dev/hda 384
A.1.2. ストライプ化マッピングターゲット
ストライプ化マッピングターゲットは物理デバイス全体でのストライピングをサポートします。これは、ストライプの数、ストライプのチャンクサイズ、およびデバイス名とセクターのペアの一覧を引数として受け取ります。ストライプ化ターゲットの形式は以下のようになります。
start lengthstriped#stripes chunk_size device1 offset1 ... deviceN offsetN
それぞれのストライプについて
device と offset のパラメーターの 1 つのセットが指定されます。
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
#stripes- 仮想デバイスのストライプの数
chunk_size- 次にスイッチするまでに各ストライプに書き込まれるセクターの数。2 の累乗であり、最低でもカーネルページサイズの大きさでなければなりません。
device- ブロックデバイス。ファイルシステム内のデバイス名で参照されるか、または
major:minorの形式でメジャー番号とマイナーの番号で参照されます。 offset- デバイス上のマッピングの始点オフセット
以下の例は、3 つのストライプと、チャンクサイズ 128 を持つストライプ化ターゲットを示しています。
0 73728 striped 3 128 8:9 384 8:8 384 8:7 9789824
- 0
- 仮想デバイス内の始点ブロック
- 73728
- このセグメントの長さ
- striped 3 128
- チャンクサイズが 128 ブロックの 3 つのデバイスにわたるストライプ
- 8:9
- 最初のデバイスのメジャー番号:マイナー番号
- 384
- 最初のデバイス上のマッピングの始点オフセット
- 8:8
- 2 つ目のデバイスのメジャー番号:マイナー番号
- 384
- 2 つ目のデバイスのマッピングの始点オフセット
- 8:7
- 3 つ目のデバイスのメジャー番号:マイナー番号
- 9789824
- 3 つ目のデバイス上のマッピングの始点オフセット
以下の例は、2 つのストライプ、256 KiB のチャンク、およびメジャー番号とマイナー番号の代わりにファイルシステム内のデバイス名で指定されたデバイスパラメーターを持つストライプ化ターゲットを示しています。
0 65536 striped 2 512 /dev/hda 0 /dev/hdb 0
A.1.3. ミラーマッピングターゲット
ミラーマッピングターゲットはミラー化した論理デバイスのマッピングをサポートします。ミラー化ターゲットの形式は次のようになります。
start lengthmirrorlog_type #logargs logarg1 ... logargN #devs device1 offset1 ... deviceN offsetN
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
log_type- 使用可能なログタイプとそれらの引数は以下のようになります。
core- ミラーはローカルであり、ミラーログはコアメモリーに保持されます。このログタイプは 1 - 3 の引数を取ります。regionsize [[
no]sync] [block_on_error] disk- ミラーはローカルであり、ミラーログはディスクに保持されます。ログタイプは 2 - 4 の引数を取ります。logdevice regionsize [[
no]sync] [block_on_error] clustered_core- ミラーはクラスター化されており、ミラーログはコアメモリーに保持されます。このログタイプは 2 - 4 の引数を取ります。regionsize UUID [[
no]sync] [block_on_error] clustered_disk- ミラーはクラスター化されており、ミラーログはディスクに保持されます。このログタイプは 3 - 5 の引数を取ります。logdevice regionsize UUID [[
no]sync] [block_on_error]
LVM は、どのリージョンがミラー (ミラー群) と同期しているかを追跡するのに使用する小さなログを維持します。regionsize 引数は、それらのリージョンのサイズを指定します。クラスター環境では、UUID 引数はミラーログデバイスに関連付けられた一意の識別子であるため、ログの状態はクラスター全体で維持することができます。オプションの[no]sync引数を使用して、ミラーを "in-sync" か "out-of-sync" として指定することができます。block_on_error引数はミラーに対して、エラーを無視するのではなくエラーに対応するように指示するために使用されます。 #log_args- マッピング内で指定されるログ引数の数
logargs- ミラー用のログ引数。提供されるログ引数の数は
#log-argsパラメーターで指定され、有効なログ引数はlog_typeパラメーターで決定されます。 #devs- ミラー内のレッグ数。デバイスとオフセットが各レッグに指定されます。
device- それぞれのレッグ用のブロックデバイス。ファイルシステム内のデバイス名で参照されるか、または
major:minorの形式でメジャーとマイナーの番号で参照されます。#devsパラメーターに示されるように、ブロックデバイスとオフセットは各ミラーレッグに指定されます。 offset- デバイス上のマッピングの始点オフセット。ブロックデバイスとオフセットは
#devsで示されるようにそれぞれのミラーレッグ用に指定されます。
以下の例は、ミラーログがディスク上に保持されたクラスター化されたミラー用のミラーマッピングターゲットを示しています。
0 52428800 mirror clustered_disk 4 253:2 1024 UUID block_on_error 3 253:3 0 253:4 0 253:5 0
- 0
- 仮想デバイス内の始点ブロック
- 52428800
- このセグメントの長さ
- mirror clustered_disk
- ミラーがクラスター化されており、ディスク上でミラーログを維持することを指定するログタイプが指定されたミラーターゲット
- 4
- 4 つのミラーログ引数が続きます
- 253:2
- ログデバイスのメジャー番号:マイナー番号
- 1024
- 同期される部分を追跡するためにミラーログが使用するリージョンのサイズ
UUID- クラスター全体でログ情報を維持するためのミラーログデバイスの UUID
block_on_error- ミラーはエラーに対応する必要があります
- 3
- ミラー内のレッグ数
- 253:3 0 253:4 0 253:5 0
- ミラーの各レッグを構成しているデバイス用のメジャー番号:マイナー番号およびオフセット
A.1.4. スナップショットとスナップショット複製元のマッピングターゲット
ボリュームの最初の LVM スナップショットを作成する場合に、4 つのデバイスマッパーデバイスが使用されます。
linearマッピングを持つデバイス。ソースボリュームの元のマッピングテーブルが含まれます。- ソースボリューム用の COW (copy-on-write) デバイスとして使用される
linearマッピングを持つデバイス。書き込みを行うたびに、元のデータは各スナップショットの COW デバイス内に保存され、その可視コンテンツはそのまま維持されます (COW デバイスが満杯になるまで)。 - 上記の 1 と 2 を組み合わせた
snapshotマッピングを持つデバイス。これは可視スナップショットボリュームです。 - 「元」のボリューム (これは、元のソースボリュームで使用されるデバイス番号を使用します)。このテーブルはデバイス #1 からの「snapshot-origin」マッピングに置き換えられます。
これらのデバイスを作成するには固定された命名スキームが使用されます。たとえば、以下のようなコマンドを使用して
base という名前の LVM ボリュームを作成し、snap という名前のスナップショットボリュームをそのボリューム上に作成することができます。
#lvcreate -L 1G -n base volumeGroup#lvcreate -L 100M --snapshot -n snap volumeGroup/base
これによって 4 つのデバイスが作成され、以下のコマンドで表示できます。
#dmsetup table|grep volumeGroupvolumeGroup-base-real: 0 2097152 linear 8:19 384 volumeGroup-snap-cow: 0 204800 linear 8:19 2097536 volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16 volumeGroup-base: 0 2097152 snapshot-origin 254:11 #ls -lL /dev/mapper/volumeGroup-*brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base
snapshot-origin ターゲットの形式は以下のようになります。
start lengthsnapshot-originorigin
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
origin- スナップショットのベースボリューム
snapshot-origin には通常、それをベースにした１つまたは複数のスナップショットがあります。読み取りは直接バッキングデバイスにマップされます。それぞれの書き込みには、元のデータが各スナップショットの COW デバイス内に保存されて、COW デバイスが満杯になるまでその可視コンテンツをそのまま維持します。
snapshot ターゲットの形式は以下のようになります。
start lengthsnapshotorigin COW-deviceP|Nchunksize
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
origin- スナップショットのベースボリューム
COW-device- 変更されたデータチャンクが保存されるデバイス
- P|N
- P (Persistent) または N (Not persistent) は、スナップショットが再起動後に維持されるかどうかを示します。一時的なスナップショット (N) には、多くのメタデータをディスク上に保存できません。メタデータはカーネルによってメモリー内に保持できます。
chunksize- COW デバイスに保存されるデータの変更したチャンクのセクターサイズ
次の例は、複製元デバイスが 254:11 の
snapshot-origin ターゲットを示しています。
0 2097152 snapshot-origin 254:11
以下の例は、複製元デバイスが 254:11 で、COW デバイスが 254:12 の
snapshot ターゲットを示しています。このスナップショットデバイスは再起動後にも永続し、COW デバイス上に保存されるデータのチャンクサイズは 16 セクターです。
0 2097152 snapshot 254:11 254:12 P 16
A.1.5. エラーマッピングターゲット
エラーマッピングターゲットを使用すると、マップされたセクターへの I/O 操作はいずれも失敗します。
エラーマッピングターゲットはテスト用に使用できます。障害時にデバイスがどのように動作するかをテストするには、１ つのデバイスの中に不良セクターがあるデバイスマッピングを 1 つ作成するか、またはミラーレッグをスワップアウトして、そのレッグをエラーターゲットに置き換えます。
エラーターゲットは、実際のデバイス上でのタイムアウトおよび再試行を回避する方法として、障害のあるデバイスの代わりに使用することができます。エラーターゲットは、障害時に LVM メタデータを再配置している間に中間ターゲットとして機能します。
error マッピングターゲットは、start と length のパラメーター以外には追加のパラメーターを取りません。
以下の例は、
error ターゲットを示しています。
0 65536 error
A.1.6. ゼロマッピングターゲット
zero マッピングターゲットは、/dev/zero と同等のブロックデバイスです。このマッピングの読み取り操作はゼロのブロックを返します。このマッピングに書き込まれたデータは破棄されますが、書き込みは正常に実行されます。zero マッピングターゲットは start と length パラメーター以外には追加のパラメーターは取りません。
以下の例は、16Tb デバイス用の
zero ターゲットを示しています。
0 65536 zero
A.1.7. マルチパスマッピングターゲット
マルチパスマッピングターゲットはマルチパス化したデバイスのマッピングをサポートします。
multipath ターゲットの形式は以下のようになります。
start lengthmultipath#features [feature1 ... featureN] #handlerargs [handlerarg1 ... handlerargN] #pathgroups pathgroup pathgroupargs1 ... pathgroupargsN
それぞれのパスグループ用に 1 つのセットの
pathgroupargs パラメーター群があります。
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
#features- マルチパス機能の数。その後にそれらの機能が続きます。このパラメーターがゼロであれば、
featureパラメーターは存在せず、次のデバイスマッピングパラメーターは#handlerargsとなります。現在、multipath.confファイルのfeatures属性で設定できるqueue_if_no_pathというサポートされている機能が 1 つあります。これは、利用可能なパスがない場合には、マルチパス化したデバイスが I/O 操作をキューに登録するよう現在設定されていることを示します。以下の例では、multipath.confファイルのno_path_retry属性が設定されています。これは、パスを使用する試行が所定回数行われた後にすべてのパスが失敗 (failed) とマークされるまで I/O 操作をキューに登録するために設定されます。この場合、すべてのパスチェッカーによるチェックが所定回数失敗するまでマッピングは以下のように表示されます。0 71014400 multipath 1 queue_if_no_path 0 2 1 round-robin 0 2 1 66:128 \ 1000 65:64 1000 round-robin 0 2 1 8:0 1000 67:192 1000
すべてのパスチェッカーがチェックに所定回数失敗した後には、マッピングは以下のように表示されます。0 71014400 multipath 0 0 2 1 round-robin 0 2 1 66:128 1000 65:64 1000 \ round-robin 0 2 1 8:0 1000 67:192 1000
#handlerargs- ハードウェアハンドラー引数の数です。それらの引数がその後に続きます。ハードウェアハンドラーは、パスグループを切り替える場合か、または I/O エラーを処理する場合に、ハードウェア固有のアクションを実行するために使用されるモジュールを指定します。これがゼロに設定されている場合は、次のパラメーターは
#pathgroupsとなります。 #pathgroups- パスグループの数です。バスグループとは、マルチパス化したデバイスがロードバランシングを行うパスのセットのことです。それぞれのパスグループに 1 つのセットの
pathgroupargsパラメーターがあります。 pathgroup- 試行する次のパスグループ
pathgroupsargs- 各パスグループは以下の引数で構成されます。
pathselector #selectorargs #paths #pathargs device1 ioreqs1 ... deviceN ioreqsNパスグループ内の各パス用にパス引数の 1 つのセットがあります。pathselector- 次の I/O 操作で使用するための、このパスグループ内のパスを決定するために使用するアルゴリズムを指定します。
#selectorargs- マルチパスマッピングでこの引数に続くパスセレクター引数の数。現在、この引数の値は常に 0 (ゼロ) です。
#paths- このパスグループ内のパスの数。
#pathargs- このグループ内の各パスに指定されたパス引数の数。現在、この数は 常に 1 で
ioreqs引数になります。 device- パスのブロックデバイス数。
major:minorの形式で、メジャー番号とマイナー番号によって参照されます。 ioreqs- 現在のグループ内の次のパスへ切り替えるまでこのパスにルーティングする I/O 要求数。
図A.1「マルチパスマッピングターゲット」 は、２つのパスグループを持つマルチパスターゲットの形式を示しています。
図A.1 マルチパスマッピングターゲット
以下の例は、同じマルチパスデバイスのための純粋なフェイルオーバーターゲットの定義を示しています。このターゲットには、4 つのパスグループがあります。マルチパス化したデバイスが 1 度に 1 つのパスのみを使用するように、パスグループごとに１ つのパスのみが開いています。
0 71014400 multipath 0 0 4 1 round-robin 0 1 1 66:112 1000 \ round-robin 0 1 1 67:176 1000 round-robin 0 1 1 68:240 1000 \ round-robin 0 1 1 65:48 1000
次の例は、同じマルチパス化したデバイスを対象とする、完全に分散した (multibus) ターゲットの定義を示しています。このターゲットでは、すべてのパスを含む 1 つのパスグループのみが存在します。このセットアップでは、マルチパスはすべてのパスに対して負荷を均等に分散します。
0 71014400 multipath 0 0 1 1 round-robin 0 4 1 66:112 1000 \ 67:176 1000 68:240 1000 65:48 1000
マルチパス化に関する詳細情報は、『DM マルチパスの使用 (Using Device Mapper Multipath)』 を参照してください。
A.1.8. 暗号マッピングターゲット
crypt ターゲットは、指定したデバイスを経由するデータの受け渡しを暗号化します。これは、カーネル Crypto API を使用します。
crypt ターゲットの形式は以下のようになります。
start lengthcryptcipher key IV-offset device offset
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
cipher- Cipher は、
cipher[-chainmode]-ivmode[:iv options]で構成されます。cipher- 利用できる Cipher は
/proc/crypto(例:aes) 内に一覧表示されています。 chainmode- 常に
cbcを使用します。ebcは 使用しません。これは初期ベクトル (IV) を使いません。 ivmode[:iv options]- IV は暗号化を変更するために使用する初期ベクトルです。IV モードは
plainまたはessiv:hashです。-plainのivmodeは、セクター番号 (および IV オフセット) を IV として使用します。-essivのivmodeはウォーターマークの弱点を回避するための機能強化です。
key- 暗号化キー (16 進数で指定)
IV-offset- 初期ベクトル (IV) オフセット
device- ブロックデバイス。ファイルシステム内のデバイス名で参照されるか、または
major:minor形式のメジャー番号とマイナー番号で参照されます。 offset- デバイス上のマッピングの始点オフセット
以下に
crypt ターゲットの例を示します。
0 2097152 crypt aes-plain 0123456789abcdef0123456789abcdef 0 /dev/hda 0
A.1.9. デバイスマッパー RAID マッピングターゲット
デバイスマッパー RAID (dm-raid) ターゲットは、DM から MD へのブリッジを提供します。これにより、MD RAID ドライバーには、デバイスマッパーインターフェースを使ってアクセスできます。dm-raid ターゲットの形式は以下のとおりです。
start lengthraidraid_type#raid_paramsraid_params#raid_devsmetadata_dev0dev0[..metadata_devNdevN]
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
raid_type- RAID タイプは以下のいずれかにすることができます。
- raid1
- RAID1 ミラーリング
- raid4
- RAID4 専用のパリティーディスク
- raid5_la
- RAID5 左非対称— パリティー 0 をローテートしてデータを継続
- raid5_ra
- RAID5 右非対称— パリティー N をローテートしてデータを継続
- raid5_ls
- RAID5 左対称— パリティー 0 をローテートしてデータを再起動
- raid5_rs
- RAID5 右対称— パリティー N をローテートしてデータを再起動
- raid6_zr
- RAID6 ゼロの再起動— パリティーゼロを (左から右に) ローテートしてデータを再起動
- raid6_nr
- RAID6 N の再起動— パリティー N を (左から右に) ローテートしてデータを再起動
- raid6_nc
- RAID6 N の継続— パリティー N を (右から左に) ローテートしてデータを継続
- raid10
- 追加のオプション引数で選択される各種の RAID10 型アルゴリズム— RAID 10: ストライプ化ミラー (ミラー上部でのストライピング)— RAID 1E: 統合された隣接のストライプ化ミラーリング— RAID 1E: 統合されたオフセットのストライプ化ミラーリング— 上記以外の同様の RAID10 のバリエーション
#raid_params- 続くパラメーターの数
raid_params- 必須パラメーター:
chunk_size- セクター単位のチャンクサイズです。このパラメーターは「ストライプサイズ」として知られることがよくあります。これは必須パラメーターのみであり、最初に配置されます。
オプションパラメーターが続きます (任意の順序):- [sync|nosync]
- RAID の初期化を強制または回避します。
- rebuild
idx - ドライブ番号
idx(最初のドライブは 0) を再構築します。 - daemon_sleep
ms - ビットをクリアする bitmap デーモンの実行間の間隔です。間隔が長くなると、ビットマップ I/O が少なくなりますが、失敗後の再同期により長い時間がかかる可能性があります。
- min_recovery_rate
KB/sec/disk - RAID スロットルの初期化
- max_recovery_rate
KB/sec/disk - RAID スロットルの初期化
- write_mostly
idx - ドライブインデックスに
idxwrite-mostly というマークを付けます。 - max_write_behind
sectors mdadmman ページの--write-behindについての説明を参照してください。- stripe_cache
sectors - ストライプキャッシュのサイズ (RAID 4/5/6 のみ)
- region_size
sectors - リージョンの数を乗じた
region_sizeはアレイの論理サイズです。ビットマップは各リージョンのデバイスの同期状態を記録します。 - raid10_copies
#copies - RAID10 コピーの数です。このパラメーターは、RAID10 設定のデフォルトレイアウトを変更するために
raid10_formatパラメーターと併用されます。デフォルト値は 2 です。 - raid10_format near|far|offset
- このパラメーターは、RAID10 設定のデフォルトレイアウトを変更するために
raid10_copiesパラメーターと併用されます。デフォルト値はnearで、この値は標準のミラーレイアウトを指定します。raid10_copiesとraid10_formatが指定されないままか、またはraid10_copies 2および/またはraid10_format nearが指定されている場合に、2、3 および 4 デバイスのレイアウトは以下のようになります。2 drives 3 drives 4 drives -------- ---------- -------------- A1 A1 A1 A1 A2 A1 A1 A2 A2 A2 A2 A2 A3 A3 A3 A3 A4 A4 A3 A3 A4 A4 A5 A5 A5 A6 A6 A4 A4 A5 A6 A6 A7 A7 A8 A8 .. .. .. .. .. .. .. .. ..
2 デバイスレイアウトは 2 方向の RAID1 と同等です。4 デバイスレイアウトは従来の RAID10 のレイアウトのようになります。3 デバイスレイアウトは「RAID1E - 統合された隣接のストライプミラーリング」のようになります。raid10_copies 2およびraid10_format farが指定される場合、2、3 および 4 デバイスのレイアウトは以下のようになります。2 drives 3 drives 4 drives -------- ----------- ------------------ A1 A2 A1 A2 A3 A1 A2 A3 A4 A3 A4 A4 A5 A6 A5 A6 A7 A8 A5 A6 A7 A8 A9 A9 A10 A11 A12 .. .. .. .. .. .. .. .. .. A2 A1 A3 A1 A2 A2 A1 A4 A3 A4 A3 A6 A4 A5 A6 A5 A8 A7 A6 A5 A9 A7 A8 A10 A9 A12 A11 .. .. .. .. .. .. .. .. ..
raid10_copies 2およびraid10_format offsetが指定されている場合、2、3 および 4 デバイスのレイアウトは以下のようになります。2 drives 3 drives 4 drives -------- -------- ------------------ A1 A2 A1 A2 A3 A1 A2 A3 A4 A2 A1 A3 A1 A2 A2 A1 A4 A3 A3 A4 A4 A5 A6 A5 A6 A7 A8 A4 A3 A6 A4 A5 A6 A5 A8 A7 A5 A6 A7 A8 A9 A9 A10 A11 A12 A6 A5 A9 A7 A8 A10 A9 A12 A11 .. .. .. .. .. .. .. .. ..
これらのレイアウトは、RAID1E - 統合されたオフセットのストライプミラーリングのレイアウトに非常によく似ています。
#raid_devs- アレイを構成するデバイスの数それぞれのデバイスは 2 つのエントリーから構成されます。最初のデバイスは、メタデータ (ある場合) を含むデバイスで、2 つ目のデバイスは、データを含むデバイスです。ドライブが失敗するか、または作成時にない場合、'-' を所定位置のメタデータとデータドライバーの両方に指定できます。
以下の例は、始点ブロックが 0 でセグメントの長さが 1960893648 の RAID4 ターゲットを示しています。4 データドライブ、1 パリティーがあり、スーパーブロック/ビットマップ情報を保持するためにメタデータデバイスは指定されておらず、チャンクサイズは 1MiB になっています。
0 1960893648 raid raid4 1 2048 5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
以下の例は、始点ブロックが 0 でセグメントの長さが 1960893648 の RAID4 ターゲットを示しています。4 データドライバー、1 パリティーがあり、メタデータデバイスの指定あるほか、チャンクサイズは 1MiB、RAID 初期化の強制、および
min_recovery レートは 20 kiB/sec/disks に指定されています。
0 1960893648 raid raid4 4 2048 sync min_recovery_rate 20 5 8:17 8:18 8:33 8:34 8:49 8:50 8:65 8:66 8:81 8:82
A.1.10. シンマッピングターゲットおよびシンプールマッピングターゲット
シンプールターゲットの形式は次のようになります。
start lengththin-poolmetadata_devdata_devdata_block_sizelow_water_mark[#feature_args[arg*] ]
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
metadata_dev- メタデータデバイス
data_dev- データデバイス
data_block_size- データブロックサイズ (セクター単位)。データブロックサイズは、512 バイトセクターで表される単位で割り当てられるディスク領域の最も小さな単位を提供します。データブロックサイズは 64KB (128 セクター) から 1GB (2097152 セクター) までの範囲になければならず、128 (64KB) の倍数でなければなりません。
low_water_mark- サイズ
data_block_sizeのブロックで表わされる低ウォーターマークです。データデバイスの空き領域がこのレベルを下回ると、ユーザースペースデーモンが取得するデバイスマッパーイベントがトリガーされ、プールデバイスを拡張できるようになります。このイベントは 1 回のみ送信されます。新規テーブル自体を使ってデバイスを再開すること自体でイベントがトリガーされるので、ユーザースペースデーモンはこれを使って、新規テーブルがしきい値を超えている状況を検出することができます。メタデータデバイス用の低ウォーターマークはカーネルに保持され、メタデータデバイスの空き容量がこのレベルを下回ると、デバイスマッパーイベントをトリガーします。 #feature_args- feature 引数の数
arg- シンプール feature 引数は以下のとおりです。
- skip_block_zeroing
- 新規にプロビジョニングされたブロックのゼロ化をスキップします。
- ignore_discard
- 破棄サポートを無効にします。
- no_discard_passdown
- 破棄内容を配下のデータデバイスに渡しません。マッピングを削除するだけです。
- read_only
- プールメタデータに対する変更を許可しません。
- error_if_no_space
- 領域がない場合のキューに登録する代わりのエラー IO です。
以下の例では、仮想デバイス内の始点ブロックが 0、セグメントの長さが 1638400 のシンプールターゲットを示しています。
/dev/sdc1 は小規模なメタデータデバイスであり、/dev/sdc2 はより大きなデータデバイスです。チャンクサイズは 64k であり、low_water_mark は 0 で、feature はありません。
0 16384000 thin-pool /dev/sdc1 /dev/sdc2 128 0 0
シンターゲットの形式は以下のようになります。
start lengththinpool_devdev_id[external_origin_dev]
start- 仮想デバイス内の始点ブロック
length- このセグメントの長さ
pool_dev- シンプールデバイスです。たとえば、
/dev/mapper/my_poolまたは 253:0 になります。 dev_id- アクティブ化されるデバイスの内部デバイス識別子です。
external_origin_dev- 読み取り専用スナップショットの複製元として処理されるプール外のオプションのブロックデバイスです。シンターゲットのプロビジョニングされていない領域の読み取りがこのデバイスにマップされます。
以下の例は、
/dev/mapper/pool をそのバッキングストア (シンプール) として使用する 1 GiB thinLV を示しています。ターゲットには、仮想デバイス内の始点ブロック 0 とセグメント長さ 2097152 があります。
0 2097152 thin /dev/mapper/pool 1
