Device mapper

from Wikipedia, the free encyclopedia

The device mapper is part of the Linux kernel (since 2.6). It allows the creation of virtual block-oriented devices by mapping their address range to other block-oriented devices or special functions. The Device Mapper is mainly used for the Logical Volume Manager (LVM) and device encryption . The Device Mapper provides some functions that LVM needs (and which were an integral part of LVM in earlier Linux versions): creation and management of block-oriented devices, snapshots (including writing the changes back to the original device ("merge")) and various RAID functions (especially striping (level 0) and mirroring (level 1)). Thanks to the separation from LVM, these functions can now also be used with other block-oriented devices (e.g. hard drives (partitions) and loop devices ). LVM and cryptsetup (LUKS) make functions of a higher level available and thus shield the user from the details that are required for direct use of the device mapper (dmsetup). Devices of the device mapper can be blocked during operation (writable, mounted file system) and largely reconfigured. Since the kernel version 3.2, the device mapper also supports thin provisioning . Similar to LVM, the multipath function is also based on the device mapper.

Structure of devices of the device mapper

Devices are created with the help of the device mapper by passing the following data to the console program dmsetup in addition to the name of the device:

  1. Starting sector
  2. Number of consecutive sectors with the same goal
  3. Target type (target)
  4. target-specific arguments

The definition of a device can consist of one or more such blocks. With the following configuration, you can connect two hard drives (100 GiB each) to a single logical drive:

0 209715200 linear / dev / sdb 0
209715200 209715200 linear / dev / sdc 0

The devices created by the device mapper appear under / dev / mapper / with the name transferred to dmsetup and under / sys / block / with the kernel name (dm-0, dm-1, ...).

The interaction of the manipulation of DM devices with udev can be controlled via dmsetup . About the daemon dmeventd may also be responding to events that DM devices concern (about to run out continuous space with thin provisioning).

Connection between device mapper and LVM

LVM tells the device mapper which blocks on a device belong to a logical drive in which order. After creating the device, it is no longer recognizable that it is an LVM device; you could also make this assignment yourself. Two drives created one after the other via LVM are shown in the Device Mapper as follows:

  1. 0 25165824 linear 8: 8 384
  2. 0 204800 linear 8: 8 29360512

8: 8 are major and minor numbers for / dev / sda8, the second number specifies the size, the last the offset to the start sector of the partition (not 0 because of the LVM metadata).

Creation of snapshots

This section refers to snapshots of volumes that are not part of a thin-pool volume, i.e. the old method. Snapshots are mostly created using LVM. The LVM programs then only display two objects: the original drive and the snapshot drive. In addition, there is currently the restriction that LVM can only create snapshot drives in the same volume group as the original drive. This is a limitation of the administration program ( lvcreate ), not of the device mapper. From his point of view, there are not two, but four devices (snapshot of the logical volume (LV) test in the volume group (VG) vg0 , name of the snapshot LV is test-snap ):

  1. vg0-test
  2. vg0-test-real
  3. vg0-test - snap
  4. vg0-test - snap-cow

The original device vg0-test is linearly rewritten from the target type to snapshot-origin, vg0-test-real has the original definition of vg0-test , under vg0-test - snap the snapshot view of the original drive is made available, and vg0-test --snap-cow is the device in which the changes made to the original device after the creation of the snapshot are logged via copy-on-write (COW). These are snapshots at the device level, not the file system level. If further snapshots are generated, an additional drive is generated from the LVM point of view, and two each from the point of view of the device mapper (snapshot and COW).

Connection between device mapper and LUKS

LUKS volumes have a header area (two MiB in the following example), the rest of which stores the encrypted data. The administration tools read the necessary parameters from the header and place a DM volume configured with these parameters over the rest. A LUKS volume does not have to be an LVM volume. Example of a 100 MiB volume:

blockdev --getsz / dev / linux / lukstest
204800

The encrypted volume created by LUKS is slightly smaller:

blockdev --getsz / dev / mapper / lukstest
200704

The device mapper sees the volume as follows (key shortened):

dmsetup table lukstest --showkeys
0 200704 crypt aes-cbc-essiv: sha256 bff5 [...] 0 253: 10 4096

As with LVM (snapshots), the possibilities of the device mapper (or dmsetup) with LUKS go beyond those of the management programs. The dmsetup functions load , suspend and resume can be used to change the size of a mounted volume, which cryptsetup does not allow.

Thin provisioning

With version 3.2, the thin and thin-pool targets became part of the Linux kernel. These targets work in such a way that first a volume for metadata (in the size of the maximum expansion; 4 MiB metadata and 16 MiB block size are sufficient for about 1.3 TiB of virtual capacity) and one for data (at least in the size of the minimum expansion) becomes. These two volumes are then connected via the target thin pool . The pool can contain multiple volumes (and snapshots of them). These are generated via messages to the pool device (dmsetup message). In contrast to the other devices generated by the device mapper, the pool device cannot be directly described as a block-oriented device. Objects that can be addressed as normal block-oriented devices are then generated via the target thin (the size of which can be increased and decreased later). The integration of the snapshot function in the pool device not only reduces memory consumption to the currently required value (which enables a larger number of snapshots), but also reduces the loss of performance in chained snapshots through an internal reorganization of the snapshot management. Several snapshots can share blocks so that storage space is only used once, but the data is visible in several volumes.

Thin provisioning supports the TRIM function , which is primarily intended for SSDs . However, the purpose of this function is not in the properties and protection of the underlying hardware, but in saving storage space, which is important because of its overcrowding.

Special targets

In addition to the most important targets linear , crypt and snapshot / snapshot-origin, the device mapper provides a number of special targets:

  1. delay: carries out read and / or write accesses with a delay and can distribute them to several devices
  2. error: Generates an I / O error for every access (especially for test purposes)
  3. flakey: generates (configurable) errors with read and / or write access (enables write access to be discarded)
  4. mirror: mirroring (RAID 1)
  5. raid: for the higher RAID levels
  6. snapshot-merge: write back changes made to a snapshot to the original volume (not possible with the root file system during operation)
  7. striped: RAID 0
  8. zero: returns only zeros for read accesses, rejects write accesses (block-oriented analogy to / dev / null ); can simulate thin provisioning together with snapshots
  9. (not in the vanilla kernel) ioband: allows the I / O bandwidth of a device to be restricted (also per user or cgroup)

Multipath

Like RAID (same data on several devices; protection against failure of the actual storage medium), professional storage systems with a high level of redundancy offer the possibility of accessing the same storage medium in different ways (protection against failure of one of the devices that the computer with the Connect storage medium). This is mainly used in systems based on Fiber Channel . On the software side, it is important that the storage medium can be addressed via a fixed name that is independent of the way in which the medium is accessed. This is achieved via the target multipath , which can be configured using many options and can even compensate for differences in speed between alternative paths to the storage medium.

Web links

Individual evidence

  1. ↑ Article at Heise online. Retrieved February 26, 2012 .
  2. ↑ Documentation of the developer. Retrieved February 26, 2012 .
  3. ↑ Kernel documentation. Retrieved February 26, 2012 .
  4. ↑ project page at sourceforge. (No longer available online.) Archived from the original on May 10, 2012 ; Retrieved February 26, 2012 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / sourceforge.net