Device Mapper
The Device Mapper is part of the Linux kernel (since 2.6). It allows the creation of virtual block devices by mapping the address space to other block devices or special functions. The Device-mapper is used primarily for the Logical Volume Manager (LVM ) and device encryption. The Device-mapper is enabled for that LVM is required ( and the integral in earlier versions of Linux part of LVM were ): creation and management of block devices, snapshots (including writing back the changes to the source device ( "Merge " ) ) and various RAID functions (especially striping (level 0) and mirroring (Level 1) ). Thanks to the removal from LVM, these functions can now also be used with other block devices (eg hard disks ( partitions ) and loop devices). LVM and cryptsetup ( LUKS ) functions provide a higher level available and shield the user from the details so from that ( dmsetup ) are required for the immediate use of the device -mapper. Device-mapper devices can be blocked (writable mounted file system ) during operation and largely reconfigured. Since kernel version 3.2 supports the Device-mapper and thin provisioning. Similar to LVM also sets the multipath function on the device -mapper.
Structure of Device-mapper devices
Devices are produced with the help of the device mappers by next to the name of the device you pass the following data to the console program dmsetup:
The definition of a device can consist of a single or a plurality of such blocks. So you can ( 100 GiB ) connect to this configuration, two hard drives into a single logical drive:
0 209715200 linear / dev / sdb 0 209715200 209715200 linear / dev / sdc 0
The devices produced by the Device-mapper appear under / dev / mapper / dmsetup with the given name and / sys / block / with the kernel name ( dm -0, dm- 1, ...).
About dmsetup the interaction of the manipulation of DM devices can be controlled with udev. Can dmeventd About the daemon also react to events that affect DM devices (such as continuous running low on disk space thin provisioning ).
Context of device -mapper and LVM
LVM tells the Device-mapper, which include blocks on a device in which sequence to a logical drive. After creating the device is no longer recognizable, that it is a LVM device; you could set this assignment by himself. Two sequentially generated by LVM drives present in the Device-mapper example this way:
8:8 are major and minor number for / dev/sda8, the second number specifies the size, the last offset to the start sector of the partition (not 0 because of the LVM metadata ).
Construction of snapshots
This section refers to snapshots of volumes that are not part of a thin -pool volumes, ie on the old process. Snapshots are usually generated by LVM. The LVM programs will show only two objects: the source drive and the snapshot disk drive. Also, a current restriction that LVM can only create snapshot drives in the same volume group as the original drive. This is a limitation of the management program ( lvcreate ), not the device mappers. From whose point of view do not exist 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 ):
The original device vg0 test is of objective type linear rewritten to snapshot- origin, vg0 -test- real has the original definition of vg0 test, under vg0 - test - snap snapshot view is made available on the source drive, and vg0 test - snap -cow is the unit in which by Copy -On- Write ( cOW) the changes made after generating the snapshot on the source device will be logged. These are snapshots device, not on the file system level. If additional snapshots generated each an additional drive is generated from LVM view from Device Mapper view two ( snapshot and COW).
Context of device -mapper and LUKS
LUKS volumes have a header area ( in the following example two MiB ), the rest stores the encrypted data. The management tools read from the header of the necessary parameters and place it over the rest of a system configured with these parameters DM volume. A LUKS volume must not be a LVM volume. Example a 100 MiB volume:
The LUKS is based, encrypted volume is somewhat smaller:
The Device-mapper sees the volume as follows ( key shortened):
As with LVM ( snapshots) are beyond the capabilities of the device - mapper (or from dmsetup ) through which the management programs at LUKS. So there is load on the dmsetup functions suspend and resume possible to change the size of a mounted volume, which cryptsetup not allowed.
Thin Provisioning
With version 3.2, the targets were thin and thin -pool part of the Linux kernel. These targets work so that initially a volume for metadata ( in the size of the maximum expansion; 4 megabytes and 16 megabytes metadata block size are sufficient for about 1.3 terabytes of virtual capacity) and one for data ( at least in the size of the minimum expansion ) produces will. These two volumes are then connected via the target thin pool. The pool can contain multiple volumes (and snapshots of these) included. These are generated via messages to the device pool ( dmsetup message). Unlike the other from the Device-mapper devices produced, the device pool can not be described directly as a block device. Then be addressed as a normal block device objects are the target thin (can be the size of which increases and decreases later ) are generated. The integration of the snapshot function in the device pool not only reduces storage consumption on the respective current required value (which allows a larger number of snapshots), but reduced by an internal reorganization of the snapshot management performance loss when concatenated snapshots. Multiple snapshots can share blocks so that only one space is occupied, but the data is visible in several volumes.
Thin Provisioning supports primarily intended for SSDs feature TRIM. The purpose of this function, however, lies not in the properties and the protection of the underlying hardware, but in saving space, which is due to the overcrowding of importance.
Specific targets
The Device-mapper is next to the main targets linear crypt and snapshot / snapshot -origin a number of specific targets available:
Multipath
Professional storage systems with a high standard of redundancy offer similar to RAID ( the same data on multiple devices, protection against the failure of the actual storage medium ) the ability to access different paths to the same storage medium ( protection against failure of one of the devices that the computer with the storage media connect ). This is used especially in systems based on Fibre Channel. On the software side is important that the storage medium via a fixed name is approachable, which is independent of being accessed which way to the media. This is achieved by the target multipath, which are configured through many options and this can even compensate for speed differences between alternative paths to the storage medium.