Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the kernel space of Device Mapper in Linux". The explanation in this article is simple and clear, easy to learn and understand. Please follow the ideas of Xiaobian to study and learn "what is the kernel space of Device Mapper in Linux" together.

Devicemapper is a generic device mapping mechanism supporting logical volume management in the kernel. It provides a highly modular kernel architecture for implementing block device drivers for storage resource management. It contains three important object concepts: Mapped Device, Mapping Table and Target device.

In the kernel, it filters or redirects IO requests through a modular target driver plug-in. The target driver plug-ins currently implemented include soft raid, soft encryption, logical volume stripe, multipath, mirror, snapshot, etc. These target drivers are represented by linear, mirror, snapshot and multipath in the figure. Device mapper further embodies the principle of separation of policy and mechanism in Linux kernel design, putting all policy-related work into user space, and mainly providing the mechanisms needed to complete these policies in the kernel. Device mapper user space is mainly responsible for configuring specific policies and control logic, such as logical devices and which physical devices to establish mappings, how to establish these mapping relationships, etc., while specific filtering and redirecting IO requests are completed by relevant code in the kernel. So the whole device mapper mechanism consists of two parts-the kernel-space device mapper driver, the user-space device mapper library, and the dmsetup tool it provides. In the following sections, we describe kernel and user space.

kernel portion

The kernel-related code of Device Mapper has been integrated into the kernel source code as part of the Linux 2.6 kernel release. The related code is in the driver/md/directory of the kernel source code. Its code file can be divided into two parts: the file implementing the basic architecture of the device mapper kernel and the target driver plug-in file implementing the specific mapping work. The analysis results below are based on the above source code files.

important concept

Device mapper is registered in the kernel as a block device driver and contains three important object concepts: mapped device, mapping table, and target device. Mapped device is a logical abstraction, which can be understood as a logical device provided by the kernel. It establishes a mapping between the mapping relationship described in the mapping table and the target device. The mapping table from a Mapped device to a target device is represented by a tuple consisting of variables representing the logical starting address of the mapped device, the range, and the address offset and target type of the physical device on which the target device resides (these addresses and offsets are in sectors of disk, i.e., 512 bytes in size). Target device represents the physical space segment mapped by mapped device. For the logical device represented by mapped device, it is a physical device mapped to the logical device. Together with the target driver plug-in, these three objects in the Device mapper form an iterable device tree. The top-level root node in this tree structure is the mapped device that is ultimately provided as a logical device, and the leaf node is the underlying physical device represented by the target device. The smallest device tree consists of a single mapped device and target device. Each target device is exclusive to a mapped device and can only be used by one mapped device. A mapped device can be mapped to one or more target devices, and a mapped device can be used as a target device of its upper mapped device, which in theory can be iterated indefinitely under the device mapper architecture.

From the above figure, we can see that mapped device1 establishes a mapping relationship with three target devices a, b and c through the mapping table, while target device a evolves through mapped device 2, and mapped device 2 establishes a mapping relationship with target device d through the mapping table.

Let's take a further look at the specific implementation of the three objects in the above figure in the code. The mapped_device structure defined in the dm.c file is used to represent the mapped device. It mainly includes the locks related to the mapped device, the registered request queues, some memory pools, and pointers to its corresponding mapping table.

The mapping table corresponding to the Mapped device is represented by the dm_table structure defined in the dm_table.c file, which contains a dm_target structure array. The dm_target structure specifically describes the mapping relationship between the mapped_device and one of its target devices.

In dm_table structure, these dm_targets are organized according to B-tree to facilitate the lookup operation when IO request mapping. The Dm_target structure specifically records the start address and range of the mapped device logical area mapped by the structure corresponding to the target device, and also contains a pointer to the target_type structure of the specific target device related operation.

Target_type structure mainly includes the name of target driver plug-in corresponding to target device, the method of defining and deleting target device of this type, IO request remapping corresponding to this type of target device and the method of ending IO, etc. The field representing the specific target device is the private field in dm_target, and this pointer points to the structure corresponding to the specific target device mapped by mapped device. The specific structure representing target device varies according to different target types. For example, the simplest linear mapping target type corresponds to the structure of target device, which is the linear_c structure defined in the dm-linear.c file. It is defined as follows:

struct linear_c { struct dm_dev *dev; sector_t start; };

The definition of target device is quite simple, including only the dm_dev structure pointer representing the corresponding physical device and the offset address start in the physical device in units of sectors. The above several data structure relationships are shown in the figure:

Build process in kernel

In the following, we briefly introduce the process of creating a mapped device in the kernel in combination with specific code:

Using the dev_create function in the dm-ioctl.c file, you create the mapped device structure based on the parameters passed through the ioctl interface provided by the kernel to user space. This process is very simple, mainly to apply to the kernel for the necessary memory resources, including mapped device and memory pool pre-applied for IO operations, through the kernel provided blk_queue_make_request function to register the request queue dm_request corresponding to the mapped device. and registers the mapped device as a disk block device in the kernel. Calling dm_hash_insert inserts the created mapped device into a global hash table in the device mapper that holds all mapped devices currently created in the kernel. The user-space command calls the table_load function via ioctl, which builds a mapping table of the specified mapped device and the mapped target device based on the parameters passed from user-space. This function first constructs the corresponding dm_table and dm_target structures, then calls the dm_table_add_target function in dm-table.c to initialize these structures according to the parameters passed by the user, and according to the target type specified by the parameters, calls the corresponding target type construction function ctr to construct the structure corresponding to the target device in memory, and then updates the B tree maintained in dm_table according to the established dm_target structure. After the above process is completed, add the established dm_table to the hash_cell structure corresponding to the global hash table of the mapped device. Finally, the binding relationship between mapped device and mapping table is established by calling the do_resume function through ioctl. In fact, the process is to assign the current dm_table structure pointer value to the map field corresponding to mapped_device through dm_swap_table function, and then modify the field where mapped_device represents the current state.

Through the four main steps described above, the device mapper creates a mapped device logical block device in the kernel that can be provided to the user.

IO stream

The essential function of the Device mapper is to forward IO requests from the logical device mapped device to the corresponding target device according to the mapping relationship and IO processing rules described by the target driver. Device mapper handles all generic_make_request and submit_bio interfaces of the Block I/O subsystem from the kernel [For detailed descriptions of the two interfaces, please refer to References [1] and [2], which have a detailed explanation of the Block I/O layer in the kernel.] All block read-write IO requests directed to mapped devices in. IO requests are processed from top to bottom in the device mapper's device tree by request forwarding. When a bio request is forwarded down the device tree at mapped dev, one or more clones of bio are created and sent to the lower target device. The same process is then repeated at each level of the device tree, and as long as the device tree is large enough the forwarding process can theoretically go on indefinitely. At a certain level in the device tree, after the target driver finishes a bio request, it reports an event indicating the end of the bio request to its upper mapped device. This process proceeds at each level until the event is finally uploaded to the root mapped device, and then the device mapper ends the original bio request on the root mapped device, ending the entire IO request process.

Bio performs layer-by-layer forwarding in the device mapper's device tree, and finally forwards to one or more leaf target nodes. Because a bio request cannot span multiple target devices (i.e., physical space segments), at each level, the device mapper clones one or more bios according to the target mapping information of the mapped device notified by the user in advance, splits the bio and forwards it to the corresponding target device. These cloned bio are first handed over to the corresponding target driver on the mapped device for processing, IO request filtering and other processing are performed according to the IO processing rules defined in the target driver, and then submitted to the target device for completion. This is done in the dm_request function in the dm.c file. The Target driver can do the following with these bios:

Queue the bio (s) inside the driver for processing; redirect the bio (s) to one or more target devices or to a different sector on each target device; and return error status to the device mapper.

The IO request is processed through the device tree shown in Figure 2 as described above until the IO request ends.

Thank you for reading, the above is "Linux Device Mapper kernel space is what" content, after the study of this article, I believe that everyone on Linux Device Mapper kernel space is what this problem has a deeper understanding, the specific use of the situation also needs to be verified. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.