Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

付録A デバイスマッパー

デバイスマッパーとは、ボリューム管理用のフレームワークを提供するカーネルドライバーです。これは論理ボリュームとして使用可能な、マップされたデバイスを作成する一般的な方法を提供します。ボリュームグループやメタデータ形式を具体的に認識するものではありません。
デバイスマッパーは多くの高度技術のための土台を提供します。LVM の他にも、デバイスマッパーマルチパスと dmraid コマンドがデバイスマッパーを使用します。デバイスマッパーに対するアプリケーションインターフェースは ioctl システムコールです。ユーザーインターフェースは dmsetup コマンドです。
LVM 論理ボリュームは、デバイスマッパーを使用してアクティブ化されます。それぞれの論理ボリュームは、マップされたデバイスに変換され、それぞれのセグメントが、そのデバイスを記述するマッピングテーブル内の行に変換されます。デバイスマッパーはリニアマッピング、ストライプ化マッピング、およびエラーマッピングを含む各種のマッピングターゲットをサポートします。ディスクがそれぞれ 1 つのリニアマッピングを持つような一対のリニアマッピングを維持する 2 つのディスクを、1 つの論理ボリュームとして連結することができます。LVM2 がボリュームを作成する場合、dmsetup コマンドでクエリ可能なデバイスマッパーデバイスを配下に作成します。マッピングテーブルのデバイスの形式に関する情報については、「デバイステーブルのマッピング」 をご覧ください。デバイスをクエリするための dmsetup コマンドの使用方法についての情報は、「dmsetup コマンド」 をご覧ください。

A.1. デバイステーブルのマッピング
リンクのコピー

マップ済デバイスは、サポートされているデバイステーブルのマッピングを使用するデバイスの論理セクターの各範囲をマッピングする方法を指定するテーブルによって定義されます。マッピング済みデバイス用のテーブルは以下の形式の行の一覧から構築されます: 
start length mapping [mapping_parameters...]
Copy to Clipboard Toggle word wrap
デバイスマッパーテーブルの最初の行では、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
Copy to Clipboard Toggle word wrap
各行の最初の 2 つのパラメーターはセグメントの始点ブロックとセグメントの長さです。次のキーワードはマッピングターゲットであり、この例内のすべてのケースで linear となります。行のその他の部分は linear ターゲットのパラメーターで構成されます。
The following subsections describe these mapping formats:
  • linear
  • striped
  • mirror
  • snapshot and snapshot-origin
  • error
  • zero
  • multipath
  • crypt
  • device-mapper RAID
  • thin
  • thin-pool

A.1.1. リニアマッピングターゲット
リンクのコピー

リニアマッピングターゲットは連続範囲のブロックを別のブロックデバイスにマップします。リニアターゲットの形式は以下のようになります: 
start length linear device offset
Copy to Clipboard Toggle word wrap
start
仮想デバイス内の始点ブロック
length
このセグメントの長さ
device
ブロックデバイス。ファイルシステム内のデバイス名で参照、または major:minor の形式のメジャー番号とマイナー番号で参照されます。
offset
デバイス上のマッピングの始点オフセット
以下の例では、仮想デバイスの始点ブロックが 0 、セグメントの長さが 1638400、メジャー/ マイナー番号ペアが 8:2、デバイス用の始点オフセットが 41146992 であるリニアターゲットを示しています。 
0 16384000 linear 8:2 41156992
Copy to Clipboard Toggle word wrap
以下の例では、デバイスパラメーターがデバイス /dev/hda として指定されたリニアターゲットを示しています。 
0 20971520 linear /dev/hda 384
Copy to Clipboard Toggle word wrap

A.1.2. ストライプ化マッピングターゲット
リンクのコピー

ストライプ化マッピングターゲットは物理デバイス全域でストライプ化をサポートします。これは、ストライプの数、ストライプのチャンクサイズ、そしてデバイス名とセクターのペアのリストを引数として取ります。ストライプ化ターゲットの形式は以下のようになります: 
start length striped #stripes chunk_size device1 offset1 ... deviceN offsetN
Copy to Clipboard Toggle word wrap
それぞれのストライプには、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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

A.1.3. ミラーマッピングターゲット
リンクのコピー

ミラーマッピングターゲットはミラー化した論理デバイスのマッピングをサポートします。ミラー化ターゲットの形式は次のようになります: 
start length mirror log_type #logargs logarg1 ... logargN #devs device1 offset1 ... deviceN offsetN
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
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 スナップショットを作成する場合に、４つのデバイスマッパーデバイスが使用されます:
  1. linear マッピングを持つデバイスが１つ。ソースボリュームのオリジナルマッピングテーブルを持っています。
  2. ソースボリューム用の COW (copy-on-write) デバイスとして使用される linear マッピングを持つデバイスが１つ。書き込みを行う度に、オリジナルデータは各スナップショットの COW デバイス内に保存され、その可視コンテンツを不変のまま維持します (COW デバイスが満杯になるまで)。
  3. 上記の 1 と 2 を組み合わせた snapshot マッピングを持つ 1 つのデバイス。これは可視のスナップショットボリュームです。
  4. "複製元" のボリューム (これは、オリジナルソースボリュームで使用されるデバイス番号を使用します)。このテーブルはデバイス #1 からの "snapshot-origin" マッピングに置き換えられます。
これらのデバイスを作成には固定の命名スキームが使用されます。例えば以下のようなコマンドを使用して base と言う名前の LVM ボリュームを作成し、snap と言う名前のスナップショットをそのボリューム上に作成することができます。 
# lvcreate -L 1G -n base volumeGroup
# lvcreate -L 100M --snapshot -n snap volumeGroup/base
Copy to Clipboard Toggle word wrap
これによって 4 つのデバイスが作成され、以下のコマンドで表示できます。 
# dmsetup table|grep volumeGroup
volumeGroup-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
Copy to Clipboard Toggle word wrap
snapshot-origin ターゲットのフォーマットは以下のようになります: 
start length snapshot-origin origin
Copy to Clipboard Toggle word wrap
start
仮想デバイス内の始点ブロック
length
このセグメントの長さ
origin
スナップショットのベースボリューム
snapshot-origin は通常、それをベースにした１つまたは複数のスナップショットを持っています。読み取りは直接バッキングデバイスにマップされます。それぞれの書き込みには、オリジナルデータが各スナップショットの COW デバイス内に保存されて、COW デバイスが満杯になるまでその可視コンテンツを不変のまま維持します。
snapshot ターゲットの形式は以下のようになります: 
start length snapshot origin COW-device P|N chunksize
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
以下の例では、複製元デバイスが 254:11 で、COW デバイスが 254:12 の snapshot ターゲットを示しています。このスナップショットデバイスは再起動後にも永続し、COW デバイス上に保存されるデータのチャンクサイズは 16 セクターです。 
0 2097152 snapshot 254:11 254:12 P 16
Copy to Clipboard Toggle word wrap

A.1.5. エラーマッピングターゲット
リンクのコピー

エラーマッピングターゲットを使用すると、マッピングされたセクターへの I/O オペレーションはいずれも失敗します。
エラーマッピングターゲットはテスト用に使用できます。障害時にデバイスがどのように動作するかをテストするには、１つのデバイスの中に不良セクターがあるデバイスマッピングを１つ作成するか、あるいは、ミラーレッグをスワップアウトして、そのレッグをエラーターゲットに置き換えます。
エラーターゲットは、実際のデバイス上でタイムアウトおよび再試行を回避する方法として、障害のあるデバイスの代わりに使用することができます。エラーターゲットは、障害時に LVM メタデータを再配置している間に中間的ターゲットとして機能します。
error マッピングターゲットは、start と length のパラメーター以外には追加のパラメーターを取りません。
以下の例では、error ターゲットを示しています。 
0 65536 error
Copy to Clipboard Toggle word wrap

A.1.6. ゼロマッピングターゲット
リンクのコピー

zero マッピングターゲットは、/dev/zero と同等のブロックデバイスです。このマッピングの読み取り操作はゼロのブロックを返します。このマッピングに書き込まれたデータは破棄されますが、書き込みは成功します。zero マッピングターゲットは start と length パラメーター以外には追加のパラメーターは取りません。
以下の例では、16Tb デバイス用の zero ターゲットを示しています。 
0 65536 zero
Copy to Clipboard Toggle word wrap

A.1.7. マルチパスマッピングターゲット
リンクのコピー

マルチパスマッピングターゲットはマルチパス化したデバイスのマッピングをサポートします。multipath ターゲットの形式は以下のようになります: 
start length  multipath  #features [feature1 ... featureN] #handlerargs [handlerarg1 ... handlerargN] #pathgroups pathgroup pathgroupargs1 ... pathgroupargsN
Copy to Clipboard Toggle word wrap
それぞれのパスグループ用に 1 つのセットの pathgroupargs パラメーター群があります。
start
仮想デバイス内の始点ブロック
length
このセグメントの長さ
#features
マルチパス機能の数。その後にその機能が続きます。このパラメーターがゼロであれば、feature パラメーターは存在せず、次のデバイスマッピングパラメーターは #handlerargs となります。現在、multipath.conf ファイルの features 属性で設定可能なサポートされている機能が 1 つあります。queue_if_no_path です。これは、パスがない場合には、マルチパス化したデバイスが I/O 操作をキューに登録するように現在セットされていることを意味します。
下記の例では、パスを使用するための試行を設定回数行った後にすべてのパスが失敗とマークされるまでのみ、multipath.conf ファイルの no_path_retry 属性は 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
Copy to Clipboard Toggle word wrap
すべてのパスチェッカーがチェックに指定回数失敗した後には、マッピングは以下のように表示されるでしょう。 
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
Copy to Clipboard Toggle word wrap
#handlerargs
ハードウェアハンドラー引数の数です。それらの引数がその後に付きます。ハードウェアハンドラーは、パスグループを切り替える時、または I/O エラーを処理する時に、ハードウェア特有のアクションを実行するために使用されるモジュールを指定します。これがゼロにセットしてある場合は、次のパラメーターは #pathgroups となります。
#pathgroups
パスグループの数です。バスグループとは、マルチパス化したデバイスがロードバランシングを行うパスのセットのことです。それぞれのパスグループに 1 つのセットの pathgroupargs パラメーターがあります。
pathgroup
試行する次のパスグループ
pathgroupsargs
各パスグループは以下の引数で構成されます: 
pathselector #selectorargs #paths #pathargs device1 ioreqs1 ... deviceN ioreqsN
Copy to Clipboard Toggle word wrap
パスグループ内の各パス用に１つのセットのパス引数群があります。
pathselector
次の I/O オペレーションで使用するのに、このパスグループ内でのパスを決定するために使用するアルゴリズムを指定します。
#selectorargs
マルチパスマッピングでこの引数に従うパスセレクター引数の数。現在、この引数の値は常に 0 (ゼロ) です。
#paths
このパスグループ内のパスの数
#pathargs
このグループ内の各パス用に指定されたパス引数の数。現在、この数は 常に 1 で ioreqs 引数です。
device
パスのブロックデバイス数。major:minor の形式で、メジャー番号とマイナー番号によって参照されます。
ioreqs
現在のグループ内の次のパスへ切り替えるまでのこのパスへルーティングする I/O 要求数。
図A.1「マルチパスマッピングターゲット」 ２つのパスグループを持つマルチパスターゲットの形式を示します。
マルチパスマッピングターゲット
View larger image
マルチパスマッピングターゲット

図A.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
Copy to Clipboard Toggle word wrap
次の例では、同じマルチパス化したデバイスを対象とする、完全に拡散した (multibus) ターゲットの定義を示しています。このターゲットでは、すべてのパスを含む１つのパスグループのみが存在しています。このセットアップでは、マルチパスはパスのすべてに渡って均等に負荷を拡散します。 
0 71014400 multipath 0 0 1 1 round-robin 0 4 1 66:112 1000 \
 67:176 1000 68:240 1000 65:48 1000
Copy to Clipboard Toggle word wrap
マルチパッシングに関する詳細情報は、『DM マルチパスの使用 (Using Device Mapper Multipath)』 をご覧ください。

A.1.8. crypt マッピングターゲット
リンクのコピー

crypt ターゲットは、指定したデバイスを経由してデータパッシングを暗号化します。これは、kernel Crypto API を使用します。
crypt ターゲットの形式は以下のようになります: 
start length crypt cipher key IV-offset device offset
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

A.1.9. The device-mapper RAID Mapping Target
リンクのコピー

The device-mapper RAID (dm-raid) target provides a bridge from DM to MD. It allows the MD RAID drivers to be accessed using a device-mapper interface. The format of the dm-raid target is as follows 
start length raid raid_type #raid_params raid_params #raid_devs metadata_dev0 dev0 [.. metadata_devN devN]
Copy to Clipboard Toggle word wrap
start
仮想デバイス内の始点ブロック
length
このセグメントの長さ
raid_type
The RAID type can be one of the following
raid1
RAID1 mirroring
raid4
RAID4 dedicated parity disk
raid5_la
RAID5 left asymmetric
— rotating parity 0 with data continuation
raid5_ra
RAID5 right asymmetric
— rotating parity N with data continuation
raid5_ls
RAID5 left symmetric
— rotating parity 0 with data restart
raid5_rs
RAID5 right symmetric
— rotating parity N with data restart
raid6_zr
RAID6 zero restart
— rotating parity 0 (left to right) with data restart
raid6_nr
RAID6 N restart
— rotating parity N (right to left) with data restart
raid6_nc
RAID6 N continue
— rotating parity N (right to left) with data continuation
raid10
Various RAID10-inspired algorithms selected by further optional arguments
— RAID 10: Striped mirrors (striping on top of mirrors)
— RAID 1E: Integrated adjacent striped mirroring
— RAID 1E: Integrated offset striped mirroring
— Other similar RAID10 variants
#raid_params
The number of parameters that follow
raid_params
Mandatory parameters:
chunk_size
Chunk size in sectors. This parameter is often known as "stripe size". It is the only mandatory parameter and is placed first.
Followed by optional parameters (in any order):
[sync|nosync]
Force or prevent RAID initialization.
rebuild idx
Rebuild drive number idx (first drive is 0).
daemon_sleep ms
Interval between runs of the bitmap daemon that clear bits. A longer interval means less bitmap I/O but resyncing after a failure is likely to take longer.
min_recovery_rate KB/sec/disk
Throttle RAID initialization
max_recovery_rate KB/sec/disk
Throttle RAID initialization
write_mostly idx
Mark drive index idx write-mostly.
max_write_behind sectors
See the description of --write-behind in the mdadm man page.
stripe_cache sectors
Stripe cache size (RAID 4/5/6 only)
region_size sectors
The region_size multiplied by the number of regions is the logical size of the array. The bitmap records the device synchronization state for each region.
raid10_copies #copies
The number of RAID10 copies. This parameter is used in conjunction with the raid10_format parameter to alter the default layout of a RAID10 configuration. The default value is 2.
raid10_format near|far|offset
This parameter is used in conjunction with the raid10_copies parameter to alter the default layout of a RAID10 configuration. The default value is near, which specifies a standard mirroring layout.
If the raid10_copies and raid10_format are left unspecified, or raid10_copies 2 and/or raid10_format near is specified, then the layouts for 2, 3 and 4 devices are as follows: 
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
..  ..      ..  ..  ..    ..  ..  ..  ..
Copy to Clipboard Toggle word wrap
The 2-device layout is equivalent to 2-way RAID1. The 4-device layout is what a traditional RAID10 would look like. The 3-device layout is what might be called a 'RAID1E - Integrated Adjacent Stripe Mirroring'.
If raid10_copies 2 and raid10_format far are specified, then the layouts for 2, 3 and 4 devices are as follows: 
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
..  ..      ..  ..  ..      ..   ..   ..   ..
Copy to Clipboard Toggle word wrap
If raid10_copies 2 and raid10_format offset are specified, then the layouts for 2, 3 and 4 devices are as follows: 
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
..  ..      ..  ..  ..     ..   ..   ..   ..
Copy to Clipboard Toggle word wrap
These layouts closely resemble the layouts fo RAID1E - Integrated Offset Stripe Mirroring'
#raid_devs
The number of devices composing the array
Each device consists of two entries. The first is the device containing the metadata (if any); the second is the one containing the data.
If a drive has failed or is missing at creation time, a '-' can be given for both the metadata and data drives for a given position.
The following example shows a RAID4 target with a starting block of 0 and a segment length of 1960893648. There are 4 data drives, 1 parity, with no metadata devices specified to hold superblock/bitmap info and a chunk size of 1MiB 
0 1960893648 raid raid4 1 2048 5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Copy to Clipboard Toggle word wrap
The following example shows a RAID4 target with a starting block of 0 and a segment length of 1960893648. there are 4 data drives, 1 parity, with metadata devices, a chunk size of 1MiB, force RAID initialization, and a min_recovery rate of 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
Copy to Clipboard Toggle word wrap

A.1.10. The thin and thin-pool Mapping Targets
リンクのコピー

The format of a thin-pool target is as follows: 
start length thin-pool metadata_dev data_dev data_block_size low_water_mark [#feature_args [arg*] ]
Copy to Clipboard Toggle word wrap
start
仮想デバイス内の始点ブロック
length
このセグメントの長さ
metadata_dev
The metadata device
data_dev
The data device
data_block_size
The data block size (in sectors). The data block size gives the smallest unit of disk space that can be allocated at a time expressed in units of 512-byte sectors. Data block size must be between 64KB (128 sectors) and 1GB (2097152 sectors) inclusive and it must be a mutlipole of 128 (64KB).
low_water_mark
The low water mark, expressed in blocks of size data_block_size. If free space on the data device drops below this level then a device-mapper event will be triggered which a user-space daemon should catch allowing it to extend the pool device. Only one such event will be sent. Resuming a device with a new table itself triggers an event so the user-space daemon can use this to detect a situation where a new table already exceeds the threshold.
A low water mark for the metadata device is maintained in the kernel and will trigger a device-mapper event if free space on the metadata device drops below it.
#feature_args
The number of feature arguments
arg
The thin pool feature argument are as follows:
skip_block_zeroing
Skip the zeroing of newly-provisioned blocks.
ignore_discard
Disable discard support.
no_discard_passdown
Do not pass discards down to the underlying data device, but just remove the mapping.
read_only
Do not allow any changes to be made to the pool metadata.
error_if_no_space
Error IOs, instead of queuing, if no space.
The following example shows a thin-pool target with a starting block in the virtual device of 0, a segment length of 1638400. /dev/sdc1 is a small metadata device and /dev/sdc2 is a larger data device. The chunksize is 64k, the low_water_mark is 0, and there are no features. 
0 16384000 thin-pool /dev/sdc1 /dev/sdc2 128 0 0
Copy to Clipboard Toggle word wrap
The format of a thin target is as follows: 
start length thin pool_dev dev_id [external_origin_dev]
Copy to Clipboard Toggle word wrap
start
仮想デバイス内の始点ブロック
length
このセグメントの長さ
pool_dev
The thin-pool device, for example /dev/mapper/my_pool or 253:0
dev_id
The internal device identifier of the device to be activated.
external_origin_dev
An optional block device outside the pool to be treated as a read-only snapshot origin. Reads to unprovisioned areas of the thin target will be mapped to this device.
The following example shows a 1 GiB thinLV that uses /dev/mapper/pool as its backing store (thin-pool). The target has a starting block in the virtual device of 0 and a segment length of 2097152. 
0 2097152 thin /dev/mapper/pool 1
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat