问在使用lvm时，如何创建/dev/dm-0和/dev/mapper/控件？

EN

您的事件序列基本上是正确的，但有以下例外：

• udev不会触发dm_mod内核模块的加载，kmod会这样做。
• 与LVM相关的udev规则是导致在新的磁盘和分区样块设备上调用pvscan的规则。pvscan通常是包含所有LVM工具的单个多调用二进制文件的一部分，并且使用libdevmapper直接与设备映射器通信，而不调用dmsetup。
• LVM工具二进制文件还直接负责读取LVM元数据和指定符号链接名称，尽管udev是底层工作人员，实际上是创建链接的工作。

哪个特定的udev规则加载dm-mod模块？

这里没有涉及到udev。这是由devtmpfs文件系统和kmod子系统处理的。当任何尝试访问不存在的/dev/mapper/control设备时，devtmpfs将搁置该请求，并启动请求kmod子系统来加载适当的模块。它最终从本质上运行modprobe devname:mapper/control，这是/lib/modules/$(uname -r)/modules.alias中定义的dm_mod的别名，它是depmod在内核安装或启动时从内核模块文件中的元数据中收集的。

一旦模块被加载并初始化(并且它已经创建了预期的设备节点)，访问尝试就会被恢复和执行，就像设备节点一直在那里一样。

哪个特定的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决定如何为其创建设备节点。