The Device Mapper

The Device Mapper is a kernel driver that provides a framework for volume management. It provides a generic way of creating mapped devices, which may be used as logical volumes. It does not specifically know about volume groups or metadata formats.

The Device Mapper provides the foundation for a number of higher-level technologies. In addition to LVM, Device-Mapper multipath and the dmraid command use the Device Mapper. The application interface to the Device Mapper is the ioctl system call. The user interface is the dmsetup command.

LVM logical volumes are activated using the Device Mapper. Each logical volume is translated into a mapped device. Each segment translates into a line in the mapping table that describes the device. The Device Mapper supports a variety of mapping targets, including linear mapping, striped mapping, and error mapping. So, for example, two disks may be concatenated into one logical volume with a pair of linear mappings, one for each disk. When LVM creates a volume, it creates an underlying device-mapper device that can be queried with the dmsetup command. For information about the format of devices in a mapping table, see Section A.1, "Device Table Mappings". For information about using the dmsetup command to query a device, see Section A.2, "The dmsetup Command".

A.1. Device Table Mappings

A mapped device is defined by a table that specifies how to map each range of logical sectors of the device using a supported Device Table mapping. The table for a mapped device is constructed from a list of lines of the form:

start length mapping [mapping_parameters...]

In the first line of a Device Mapper table, the start parameter must equal 0. The start + length parameters on one line must equal the start on the next line. Which mapping parameters are specified in a line of the mapping table depends on which mapping type is specified on the line.

Sizes in the Device Mapper are always specified in sectors (512 bytes).

When a device is specified as a mapping parameter in the Device Mapper, it can be referenced by the device name in the filesystem (for example, /dev/hda) or by the major and minor numbers in the format major:minor. The major:minor format is preferred because it avoids pathname lookups.

The following shows a sample mapping table for a device. In this table there are four linear targets:

0 35258368 linear 8:48 6592035258368 35258368 linear 8:32 6592070516736 17694720 linear 8:16 1769497688211456 17694720 linear 8:16 256

The first 2 parameters of each line are the segment starting block and the length of the segment. The next keyword is the mapping target, which in all of the cases in this example is linear. The rest of the line consists of the parameters for a linear target.

The following subsections describe the format of the following mappings:

linear
striped
mirror
snapshot and snapshot-origin
error
zero
multipath
crypt

A.1.1. The linear Mapping Target

A linear mapping target maps a continuous range of blocks onto another block device. The format of a linear target is as follows:

start length linear device offset

start: starting block in virtual device
length: length of this segment
device: block device, referenced by the device name in the filesystem or by the major and minor numbers in the format major:minor
offset: starting offset of the mapping on the device

The following example shows a linear target with a starting block in the virtual device of 0, a segment length of 1638400, a major:minor number pair of 8:2, and a starting offset for the device of 41146992.

0 16384000 linear 8:2 41156992

The following example shows a linear target with the device parameter specified as the device /dev/hda.

0 20971520 linear /dev/hda 384

A.1.2. The striped Mapping Target

The striped mapping target supports striping across physical devices. It takes as arguments the number of stripes and the striping chunk size followed by a list of pairs of device name and sector. The format of a striped target is as follows:

start length striped #stripes chunk_size device1 offset1 ... deviceN offsetN

There is one set of device and offset parameters for each stripe.

start: starting block in virtual device
length: length of this segment
#stripes: number of stripes for the virtual device
chunk_size: number of sectors written to each stripe before switching to the next; must be power of 2 at least as big as the kernel page size
device: block device, referenced by the device name in the filesystem or by the major and minor numbers in the format major:minor.
offset: starting offset of the mapping on the device

The following example shows a striped target with three stripes and a chunk size of 128:

0 73728 striped 3 128 8:9 384 8:8 384 8:7 9789824

0: starting block in virtual device
73728: length of this segment
striped 3 128: stripe across three devices with chunk size of 128 blocks
8:9: major:minor numbers of first device
384: starting offset of the mapping on the first device
8:8: major:minor numbers of second device
384: starting offset of the mapping on the second device
8:7: major:minor numbers of third device
9789824: starting offset of the mapping on the third device

The following example shows a striped target for 2 stripes with 256 KiB chunks, with the device parameters specified by the device names in the file system rather than by the major and minor numbers.

0 65536 striped 2 512 /dev/hda 0 /dev/hdb 0

A.1.3. The mirror Mapping Target

The mirror mapping target supports the mapping of a mirrored logical device. The format of a mirrored target is as follows:

start length mirror log_type #logargs logarg1 ... logargN #devs device1 offset1 ... deviceN offsetN

start

starting block in virtual device

length

length of this segment

log_type

The possible log types and their arguments are as follows:

core: The mirror is local and the mirror log is kept in core memory. This log type takes 1 - 3 arguments:
regionsize [[no]sync] [block_on_error]
disk: The mirror is local and the mirror log is kept on disk. This log type takes 2 - 4 arguments:
logdevice regionsize [[no]sync] [block_on_error]
clustered_core: The mirror is clustered and the mirror log is kept in core memory. This log type takes 2 - 4 arguments:
regionsize UUID [[no]sync] [block_on_error]
clustered_disk: The mirror is clustered and the mirror log is kept on disk. This log type takes 3 - 5 arguments:
logdevice regionsize UUID [[no]sync] [block_on_error]

LVM maintains a small log which it uses to keep track of which regions are in sync with the mirror or mirrors. The regionsize argument specifies the size of these regions.

In a clustered environment, the UUID argument is a unique identifier associated with the mirror log device so that the log state can be maintained throughout the cluster.

The optional [no]sync argument can be used to specify the mirror as "in-sync" or "out-of-sync". The block_on_error argument is used to tell the mirror to respond to errors rather than ignoring them.

#log_args

number of log arguments that will be specified in the mapping

logargs

the log arguments for the mirror; the number of log arguments provided is specified by the #log-args parameter and the valid log arguments are determined by the log_type parameter.

#devs

the number of legs in the mirror; a device and an offset is specified for each leg

device

block device for each mirror leg, referenced by the device name in the filesystem or by the major and minor numbers in the format major:minor. A block device and offset is specified for each mirror leg, as indicated by the #devs parameter.

offset

starting offset of the mapping on the device. A block device and offset is specified for each mirror leg, as indicated by the #devs parameter.

The following example shows a mirror mapping target for a clustered mirror with a mirror log kept on disk.

0 52428800 mirror clustered_disk 4 253:2 1024 UUID block_on_error 3 253:3 0 253:4 0 253:5 0

0: starting block in virtual device
52428800: length of this segment
mirror clustered_disk: mirror target with a log type specifying that mirror is clustered and the mirror log is maintained on disk
4: 4 mirror log arguments will follow
253:2: major:minor numbers of log device
1024: region size the mirror log uses to keep track of what is in sync
UUID: UUID of mirror log device to maintain log information throughout a cluster
block_on_error: mirror should respond to errors
3: number of legs in mirror
253:3 0 253:4 0 253:5 0: major:minor numbers and offset for devices constituting each leg of mirror

A.1.4. The snapshot and snapshot-origin Mapping Targets

When you create the first LVM snapshot of a volume, four Device Mapper devices are used:

A device with a linear mapping containing the original mapping table of the source volume.
A device with a linear mapping used as the copy-on-write (COW) device for the source volume; for each write, the original data is saved in the COW device of each snapshot to keep its visible content unchanged (until the COW device fills up).
A device with a snapshot mapping combining #1 and #2, which is the visible snapshot volume.
The "original" volume (which uses the device number used by the original source volume), whose table is replaced by a "snapshot-origin" mapping from device #1.

A fixed naming scheme is used to create these devices, For example, you might use the following commands to create an LVM volume named base and a snapshot volume named snap based on that volume.

# lvcreate -L 1G -n base volumeGroup# lvcreate -L 100M --snapshot -n snap volumeGroup/base

This yields four devices, which you can view with the following commands:

# dmsetup table|grep volumeGroupvolumeGroup-base-real: 0 2097152 linear 8:19 384volumeGroup-snap-cow: 0 204800 linear 8:19 2097536volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16volumeGroup-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-realbrw-------  1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cowbrw-------  1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snapbrw-------  1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base

The format for the snapshot-origin target is as follows:

start length snapshot-origin origin

start: starting block in virtual device
length: length of this segment
origin: base volume of snapshot

The snapshot-origin will normally have one or more snapshots based on it. Reads will be mapped directly to the backing device. For each write, the original data will be saved in the COW device of each snapshot to keep its visible content unchanged until the COW device fills up.

The format for the snapshot target is as follows:

start length snapshot origin COW-device P|N chunksize

start: starting block in virtual device
length: length of this segment
origin: base volume of snapshot
COW-device: Device on which changed chunks of data are stored
P|N: P (Persistent) or N (Not persistent); indicates whether snapshot will survive after reboot. For transient snapshots (N) less metadata must be saved on disk; they can be kept in memory by the kernel.
chunksize: Size in sectors of changed chunks of data that will be stored on the COW device

The following example shows a snapshot-origin target with an origin device of 254:11.

0 2097152 snapshot-origin 254:11

The following example shows a snapshot target with an origin device of 254:11 and a COW device of 254:12. This snapshot device is persistent across reboots and the chunk size for the data stored on the COW device is 16 sectors.

0 2097152 snapshot 254:11 254:12 P 16

A.1.5. The error Mapping Target

With an error mapping target, any I/O operation to the mapped sector fails.

An error mapping target can be used for testing. To test how a device behaves in failure, you can create a device mapping with a bad sector in the middle of a device, or you can swap out the leg of a mirror and replace the leg with an error target.

An error target can be used in place of a failing device, as a way of avoiding timeouts and retries on the actual device. It can serve as an intermediate target while you rearrange LVM metadata during failures.

The error mapping target takes no additional parameters besides the start and length parameters.

The following example shows an error target.

0 65536 error

A.1.6. The zero Mapping Target

The zero mapping target is a block device equivalent of /dev/zero. A read operation to this mapping returns blocks of zeros. Data written to this mapping is discarded, but the write succeeds. The zero mapping target takes no additional parameters besides the start and length parameters.

The following example shows a zero target for a 16Tb Device.

0 65536 zero

A.1.7. The multipath Mapping Target

The multipath mapping target supports the mapping of a multipathed device. The format for the multipath target is as follows:

start length  multipath  #features [feature1 ... featureN] #handlerargs [handlerarg1 ... handlerargN] #pathgroups pathgroup pathgroupargs1 ... pathgroupargsN

There is one set of pathgroupargs parameters for each path group.

start

starting block in virtual device

length

length of this segment

#features

The number of multipath features, followed by those features. If this parameter is zero, then there is no feature parameter and the next device mapping parameter is #handlerargs. Currently there is one supported feature that can be set with the features attribute in the multipath.conf file, queue_if_no_path. This indicates that this multipathed device is currently set to queue I/O operations if there is no path available.

In the following example, the no_path_retry attribute in the multipath.conf file has been set to queue I/O operations only until all paths have been marked as failed after a set number of attempts have been made to use the paths. In this case, the mapping appears as follows until all the path checkers have failed the specified number of checks.

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

After all the path checkers have failed the specified number of checks, the mapping would appear as follows.

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

The number of hardware handler arguments, followed by those arguments. A hardware handler specifies a module that will be used to perform hardware-specific actions when switching path groups or handling I/O errors. If this is set to 0, then the next parameter is #pathgroups.

#pathgroups

The number of path groups. A path group is the set of paths over which a multipathed device will load balance. There is one set of pathgroupargs parameters for each path group.

pathgroup

The next path group to try.

pathgroupsargs

Each path group consists of the following arguments:

pathselector #selectorargs #paths #pathargs device1 ioreqs1 ... deviceN ioreqsN

There is one set of path arguments for each path in the path group.

pathselector: Specifies the algorithm in use to determine what path in this path group to use for the next I/O operation.
#selectorargs: The number of path selector arguments which follow this argument in the multipath mapping. Currently, the value of this argument is always 0.
#paths: The number of paths in this path group.
#pathargs: The number of path arguments specified for each path in this group. Currently this number is always 1, the ioreqs argument.
device: The block device number of the path, referenced by the major and minor numbers in the format major:minor
ioreqs: The number of I/O requests to route to this path before switching to the next path in the current group.

Figure A.1, "Multipath Mapping Target" shows the format of a multipath target with two path groups.

Figure A.1. Multipath Mapping Target

The following example shows a pure failover target definition for the same multipath device. In this target there are four path groups, with only one open path per path group so that the multipathed device will use only one path at a time.

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

The following example shows a full spread (multibus) target definition for the same multipathed device. In this target there is only one path group, which includes all of the paths. In this setup, multipath spreads the load evenly out to all of the paths.

0 71014400 multipath 0 0 1 1 round-robin 0 4 1 66:112 1000 \ 67:176 1000 68:240 1000 65:48 1000

For further information about multipathing, see the Using Device Mapper Multipath document.

A.1.8. The crypt Mapping Target

The crypt target encrypts the data passing through the specified device. It uses the kernel Crypto API.

The format for the crypt target is as follows:

start length crypt cipher key IV-offset device offset

start

starting block in virtual device

length

length of this segment

cipher

Cipher consists of cipher[-chainmode]-ivmode[:iv options].

cipher: Ciphers available are listed in /proc/crypto (for example, aes).
chainmode: Always use cbc. Do not use ebc; it does not use an initial vector (IV).
ivmode[:iv options]: IV is an initial vector used to vary the encryption. The IV mode is plain or essiv:hash. An ivmode of -plain uses the sector number (plus IV offset) as the IV. An ivmode of -essiv is an enhancement avoiding a watermark weakness.

key

Encryption key, supplied in hex

IV-offset

Initial Vector (IV) offset

device

block device, referenced by the device name in the filesystem or by the major and minor numbers in the format major:minor

offset

starting offset of the mapping on the device

The following is an example of a crypt target.

0 2097152 crypt aes-plain 0123456789abcdef0123456789abcdef 0 /dev/hda 0

A.2. The dmsetup Command

The dmsetup command is a command line wrapper for communication with the Device Mapper. For general system information about LVM devices, you may find the info, ls, status, and deps options of the dmsetup command to be useful, as described in the following subsections.

For information about additional options and capabilities of the dmsetup command, see the dmsetup(8) man page.

A.2.1. The dmsetup info Command

The dmsetup info device command provides summary information about Device Mapper devices. If you do not specify a device name, the output is information about all of the currently configured Device Mapper devices. If you specify a device, then this command yields information for that device only.

The dmsetup info command provides information in the following categories:

Name: The name of the device. An LVM device is expressed as the volume group name and the logical volume name separated by a hyphen. A hyphen in the original name is translated to two hyphens.
State: Possible device states are SUSPENDED, ACTIVE, and READ-ONLY. The dmsetup suspend command sets a device state to SUSPENDED. When a device is suspended, all I/O operations to that device stop. The dmsetup resume command restores a device state to ACTIVE.
Read Ahead: The number of data blocks that the system reads ahead for any open file on which read operations are ongoing. By default, the kernel chooses a suitable value automatically. You can change this value with the --readahead option of the dmsetup command.
Tables present: Possible states for this category are LIVE and INACTIVE. An INACTIVE state indicates that a table has been loaded which will be swapped in when a dmsetup resume command restores a device state to ACTIVE, at which point the table's state becomes LIVE. For information, see the dmsetup man page.
Open count: The open reference count indicates how many times the device is opened. A mount command opens a device.
Event number: The current number of events received. Issuing a dmsetup wait n command allows the user to wait for the n'th event, blocking the call until it is received.
Major, minor: Major and minor device number
Number of targets: The number of fragments that make up a device. For example, a linear device spanning 3 disks would have 3 targets. A linear device composed of the beginning and end of a disk, but not the middle would have 2 targets.
UUID: UUID of the device.

The following example shows partial output for the dmsetup info command.

# dmsetup infoName:  testgfsvg-testgfslv1State: ACTIVERead Ahead: 256Tables present: LIVEOpen count: 0Event number:  0Major, minor:  253, 2Number of targets: 2UUID: LVM-K528WUGQgPadNXYcFrrf9LnPlUMswgkCkpgPIgYzSvigM7SfeWCypddNSWtNzc2N...Name:  VolGroup00-LogVol00State: ACTIVERead Ahead: 256Tables present: LIVEOpen count: 1Event number:  0Major, minor:  253, 0Number of targets: 1UUID: LVM-tOcS1kqFV9drb0X1Vr8sxeYP0tqcrpdegyqj5lZxe45JMGlmvtqLmbLpBcenh2L3

A.2.2. The dmsetup ls Command

You can list the device names of mapped devices with the dmsetup ls command. You can list devices that have at least one target of a specified type with the dmsetup ls --target target_type command. For other options of the dmsetup ls, see the dmsetup man page.

The following example shows the command to list the device names of currently configured mapped devices.

# dmsetup lstestgfsvg-testgfslv3 (253:4)testgfsvg-testgfslv2 (253:3)testgfsvg-testgfslv1 (253:2)VolGroup00-LogVol01 (253:1)VolGroup00-LogVol00 (253:0)

The following example shows the command to list the devices names of currently configured mirror mappings.

# dmsetup ls --target mirrorlock_stress-grant--02.1722  (253, 34)lock_stress-grant--01.1720  (253, 18)lock_stress-grant--03.1718  (253, 52)lock_stress-grant--02.1716  (253, 40)lock_stress-grant--03.1713  (253, 47)lock_stress-grant--02.1709  (253, 23)lock_stress-grant--01.1707  (253, 8)lock_stress-grant--01.1724  (253, 14)lock_stress-grant--03.1711  (253, 27)

LVM configurations that are stacked on multipath or other device mapper devices can be complex to sort out. The dmsetup ls command provides a --tree option that displays dependencies between devices as a tree, as in the following example.

# dmsetup ls --treevgtest-lvmir (253:13) ├─vgtest-lvmir_mimage_1 (253:12) │  └─mpathep1 (253:8) │ └─mpathe (253:5) │ ├─ (8:112) │ └─ (8:64) ├─vgtest-lvmir_mimage_0 (253:11) │  └─mpathcp1 (253:3) │ └─mpathc (253:2) │ ├─ (8:32) │ └─ (8:16) └─vgtest-lvmir_mlog (253:4) └─mpathfp1 (253:10)   └─mpathf (253:6)  ├─ (8:128)  └─ (8:80)

A.2.3. The dmsetup status Command

The dmsetup status device command provides status information for each target in a specified device. If you do not specify a device name, the output is information about all of the currently configured Device Mapper devices. You can list the status only of devices that have at least one target of a specified type with the dmsetup status --target target_type command.

The following example shows the command to list the status of the targets in all currently configured mapped devices.

# dmsetup statustestgfsvg-testgfslv3: 0 312352768 linear testgfsvg-testgfslv2: 0 312352768 linear testgfsvg-testgfslv1: 0 312352768 linear testgfsvg-testgfslv1: 312352768 50331648 linear VolGroup00-LogVol01: 0 4063232 linear VolGroup00-LogVol00: 0 151912448 linear

A.2.4. The dmsetup deps Command

The dmsetup deps device command provides a list of (major, minor) pairs for devices referenced by the mapping table for the specified device. If you do not specify a device name, the output is information about all of the currently configured Device Mapper devices.

The following example shows the command to list the dependencies of all currently configured mapped devices.

# dmsetup depstestgfsvg-testgfslv3: 1 dependencies : (8, 16)testgfsvg-testgfslv2: 1 dependencies : (8, 16)testgfsvg-testgfslv1: 1 dependencies : (8, 16)VolGroup00-LogVol01: 1 dependencies : (8, 2)VolGroup00-LogVol00: 1 dependencies : (8, 2)

The following example shows the command to list the dependencies only of the device lock_stress-grant--02.1722:

# dmsetup deps lock_stress-grant--02.17223 dependencies  : (253, 33) (253, 32) (253, 31)

A.3. Device Mapper Support for the udev Device Manager

The primary role of the udev device manager is to provide a dynamic way of setting up nodes in the /dev directory. The creation of these nodes is directed by the application of udev rules in userspace. These rules are processed on udev events sent from the kernel directly as a result of adding, removing or changing particular devices. This provides a convenient and central mechanism for hotplugging support.

Besides creating the actual nodes, the udev device manager is able to create symbolic links which the user can name. This provides users the freedom to choose their own customized naming and directory structure in the/dev directory, if needed.

Each udev event contains basic information about the device being processed, such as its name, the subsystem it belongs to, the device's type, its major and minor number used, and the type of the event. Given that, and having the possibility of accessing all the information found in the /sys directory that is also accessible within udev rules, the users are able to utilize simple filters based on this information and run the rules conditionally based on this information.

The udev device manager also provides a centralized way of setting up the nodes' permissions. A user can easily add a customized set of rules to define the permissions for any device specified by any bit of information that is available while processing the event.

It is also possible to add program hooks in udev rules directly. The udev device manager can call these programs to provide further processing that is needed to handle the event. Also, the program can export environment variables as a result of this processing. Any results given can be used further in the rules as a supplementary source of information.

Any software using the udev library is able to receive and process udev events with all the information that is available, so the processing is not bound to the udev daemon only.

A.3.1. udev Integration with the Device Mapper

In Red Hat Enterprise Linux 6, the Device Mapper provides direct support for udev integration. This synchronizes the Device Mapper with all udev processing related to Device Mapper devices, including LVM devices. The synchronization is needed since the rule application in the udev daemon is a form of parallel processing with the program that is the source of the device's changes (such as dmsetup and LVM). Without this support, it was a common problem for a user to try to remove a device that was still open and processed by udev rules as a result of a previous change event; this was particularly common when there was a very short time between changes for that device.

The Red Hat Enterprise Linux 6 release provides officially supported udev rules for Device Mapper devices in general and for LVM as well. Table A.1, "udev Rules for Device-Mapper Devices" summarizes these rules, which are installed in /lib/udev/rules.d.

Table A.1. udev Rules for Device-Mapper Devices

Filename Description

10-dm.rules

Contains basic/general Device Mapper rules and creates the symlinks in /dev/mapper with a /dev/dm-N target where N is a number assigned dynamically to a device by the kernel (/dev/dm-N is a node)

NOTE: /dev/dm-N nodes should never be used in scripts to access the device since the N number is assigned dynamically and changes with the sequence of how devices are activated. Therefore, true names in the /dev/mapper directory should be used. This layout is to support udev requirements of how nodes/symlinks should be created.

11-dm-lvm.rules

Contains rules applied for LVM devices and creates the symlinks for the volume group's logical volumes. The symlinks are created in the /dev/vgname directory with a /dev/dm-N target.

NOTE: To be consistent with the standard for naming all future rules for Device Mapper subsystems, udev rules should follow the format 11-dm-subsystem_name.rules. Any libdevmapper users providing udev rules as well should follow this standard.

13-dm-disk.rules Contains rules to be applied for all Device Mapper devices in general and creates symlinks in the /dev/disk/by-id, /dev/disk/by-uuid and the /dev/disk/by-uuid directories.

95-dm-notify.rules Contains the rule to notify the waiting process using libdevmapper (just like LVM and dmsetup). The notification is done after all previous rules are applied, to ensure any udev processing is complete. Notified process is then resumed.

You can add additional customized permission rules by means of the 12-dm-permissions.rules file. This file is not installed in the /lib/udev/rules directory; it is found in the /usr/share/doc/device-mapper-version directory. The 12-dm-permissions.rules file is a template containing hints for how to set the permissions, based on some matching rules given as an example; the file contains examples for some common situations. You can edit this file and place it manually in the /etc/udev/rules.d directory where it will survive updates, so the settings will remain.

These rules set all basic variables that could be used by any other rules while processing the events.

The following variables are set in 10-dm.rules:

DM_NAME: Device Mapper device name
DM_UUID: Device Mapper device UUID
DM_SUSPENDED: the suspended state of Device Mapper device
DM_UDEV_RULES_VSN: udev rules version (this is primarily for all other rules to check that previously mentioned variables are set directly by official Device Mapper rules)

The following variables are set in 11-dm-lvm.rules:

DM_LV_NAME: logical volume name
DM_VG_NAME: volume group name
DM_LV_LAYER: LVM layer name

All these variables can be used in the 12-dm-permissions.rules file to define a permission for specific Device Mapper devices, as documented in the 12-dm-permissions.rules file.

A.3.2. Commands and Interfaces that Support udev

Table A.2, "dmsetup Commands to Support udev" summarizes the dmsetup commands that support udev integration.

Table A.2. dmsetup Commands to Support udev

Command	Description
`dmsetup udevcomplete`	Used to notify that udev has completed processing the rules and unlocks waiting process (called from within `udev` rules in `95-dm-notify.rules`).
`dmsetup udevcomplete_all`	Used for debugging purposes to manually unlock all waiting processes.
`dmsetup udevcookies`	Used for debugging purposes, to show all existing cookies (system-wide semaphores).
`dmsetup udevcreatecookie`	Used to create a cookie (semaphore) manually. This is useful to run more processes under one synchronization resource.
`dmsetup udevreleasecookie`	Used to wait for all `udev` processing related to all processes put under that one synchronization cookie.

The dmsetup options that support udev integration are as follows.

--udevcookie

Needs to be defined for all dmsetup processes we would like to add into a udev transaction. It is used in conjunction with udevcreatecookie and udevreleasecookie:

COOKIE=$(dmsetup udevcreatecookie)  dmsetup command --udevcookie $COOKIE ....  dmsetup command --udevcookie $COOKIE ....  ....  dmsetup command --udevcookie $COOKIE ....dmsetup udevreleasecookie --udevcookie $COOKIE

Besides using the --udevcookie option, you can just export the variable into an environment of the process:

export DM_UDEV_COOKIE=$(dmsetup udevcreatecookie)  dmsetup command ...  dmsetup command ...  ...  dmsetup command ...

--noudevrules

Disables udev rules. Nodes/symlinks will be created by libdevmapper itself (the old way). This option is for debugging purposes, if udev does not work correctly.

--noudevsync

Disables udev synchronization. This is also for debugging purposes.

For more information on the dmsetup and its options, see the dmsetup(8) man page.

The LVM commands support the following options that support udev integration:

--noudevrules: as for the dmsetup command, disables udev rules.
--noudevsync: as for the dmsetup command, disables udev synchronization.

The lvm.conf file includes the following options that support udev integration:

udev_rules: enables/disables udev_rules for all LVM2 commands globally.
udev_sync: enables/disables udev synchronization for all LVM commands globally.

For more information on the lvm.conf file options, see the inline comments in the lvm.conf file.

Logical Volume Manager Administration

Chapter 7. LVM Administration with the LVM GUI

The Device Mapper

A.1. Device Table Mappings

A.1.1. The linear Mapping Target

A.1.2. The striped Mapping Target

A.1.3. The mirror Mapping Target

A.1.4. The snapshot and snapshot-origin Mapping Targets

A.1.5. The error Mapping Target

A.1.6. The zero Mapping Target

A.1.7. The multipath Mapping Target

A.1.8. The crypt Mapping Target

A.2. The dmsetup Command

A.2.1. The dmsetup info Command

A.2.2. The dmsetup ls Command

A.2.3. The dmsetup status Command

A.2.4. The dmsetup deps Command

A.3. Device Mapper Support for the udev Device Manager

A.3.1. udev Integration with the Device Mapper

A.3.2. Commands and Interfaces that Support udev