lvmを使用するときに/dev/dm-0と/dev/mapper/controlをどのように生成しますか?

lvmを使用するときに/dev/dm-0と/dev/mapper/controlをどのように生成しますか?

AFAIKの実装は、デフォルトでコマンドを介してカーネルのデバイスマッパーメカニズム(モジュール)を使用してlvmマッピングテーブルを設定するユーザースペースにあります。dm-moddmsetup

これが最終的に発生した一連の出来事であることは正しいですか/dev/dm-x

  • ブロックデバイスがオンラインになります。
  • udevパーティションからブロックデバイスを検索し、パーティションの最初の数セクタでlvmボリュームグループ/論理ボリュームメタデータを識別するルールをトリガします(通過dmsetup?)。
  • その後、ルールはモジュールudevをロードdm-modし、dmsetupを呼び出してという新しいデバイスを作成し、上記/dev/dm-xのメタデータにマッピングテーブルを設定します。
  • 他のいくつかのudev規則は、次のシンボリックリンクを生成します。/dev/mapper/vg_name-lv_name

以下は質問です。

  • モジュールをロードする特定のudev規則は何ですか?dm-mod
  • udevこのファイルを生成する特定の規則は何ですか/dev/mapper/control
  • どの特定のudevルール/dev/dm-xがファイルを生成しますか?

私はそれらがどこから来たのかを大まかに知っていますが(xx-dm.rules後でシンボリックリンクをxx-dm-lvm.rules追加するだけです/dev/vg_name/lv_name)、そのファイルのどの行が正確にこれらのタスクを実行しますか?

ベストアンサー1

以下を除いて、イベントの順序はほとんど正確です。

  • udevつまりdm_mod、カーネルモジュールのロードをトリガーしません。kmod
  • pvscanLVMに最も関連するudevルールは、ディスクやパーティションなどの新しいブロックデバイスで呼び出しが行われるようにするルールです。これは通常、すべてのLVMツールを含み、呼び出しなしでデバイスマッパーと直接通信するpvscanために使用される単一のマルチコールバイナリの一部です。libdevmapperdmsetup
  • LVMツールバイナリはLVMメタデータを読み取り、シンボリックリンク名を指定することも直接担当しますが、リンクをudev生成する実際の作業は最終的に下位レベルのワーカーによって実行されます。

モジュールをロードする特定のudev規則は何ですか?dm-mod

udevここでは扱いません。これはdevtmpfsファイルシステムとサブシステムによってkmod処理されます。/dev/mapper/control存在しないデバイスにアクセスしようとすると、devtmpfs要求が保留され、kmodサブシステムに適切なモジュールをロードするように要求が開始されます。最終的に本質的に実行されるのは、modprobe devname:mapper/controlカーネルモジュールで定義されたエイリアスです。これは、カーネルのインストールまたは起動時にカーネルモジュールファイルのメタデータから収集されます。dm_mod/lib/modules/$(uname -r)/modules.aliasdepmod

モジュールがロードされ初期化されると(予想デバイスノードが作成された場合)、アクセス試行が再開され、デバイスノードが常に存在していたかのように実行されます。

udevこのファイルを生成する特定の規則は何ですか/dev/mapper/control

デバイスノードにはudevルールがまったくない場合があり、エンドデバイスの権限を調整するためのいくつかの展開固有のルールしかありません。dm_modカーネルモジュールが初期化されたら、misc_register()カーネル機能を使用してデバイスノードの作成プロセスを開始します。カーネルコードは、デフォルト名と他のデフォルトパラメータを提供します。。これはデバイスマッパーサブシステムを制御するために使用される標準の静的デバイス名であるため、通常デフォルト値を/dev/mapper/control変更しすぎる理由はありません。

どの特定のudevルール/dev/dm-xがファイルを生成しますか?

同様にudev、デバイスの作成は開始されません。カーネル関数が呼び出されると、カーネル内のデバイスマッパーサブシステムでイニシアチブが提供されますregister_blkdev()。デバイスマッパーがデバイスを作成すると指定した場合(指定された基本名およびその他の基本属性があります。)、udevリクエストのパラメータを調整し、他のアクションをデバイスイベントにリンクしてから、ユーザ空間mknod()システムコールを使用して、カーネルのリクエスト+ udevルールに従ってデバイスノード作成要求を完了するだけです。

リクエストにudevルールが適用されない場合、デバイスudevマッパーカーネルコードで指定されたデフォルト名、所有権、権限、およびその他の属性のみを使用してデバイスが生成されます。より高いレベルのサブシステム(たとえば、LVM)が新しいマッピングの作成を要求したときに、これらのパラメーターの一部がより高いレベルのサブシステムによって指定されている可能性があります。

新しいデバイスに対してudevルールをいくらか生成できますが、ルールのパラメータと一致するデバイスを登録するためにカーネルコードが呼び出されない限り、ルールはアイドル状態にあり、何もしません。

最新のカーネル機能を使用すると、発信者はデバイス名のみを指定register_blkdev()できますregister_chrdev()。長期的な目標は、ほとんど/すべてのデバイスのメジャー/マイナー番号を動的に割り当て、udevにすべての権限割り当てを処理させることです。ただし、以前のバージョンではmisc_register()デバイス構造全体を指定できるため、静的メジャー/マイナーノード番号やその他の属性を持つデバイスを作成できます。

マスエフェクト2:カーネル決定に頼るならいつデバイスをudev決定してください。どのようにこれに対してデバイスノードを作成します。

おすすめ記事