Hi,

I am just trying to understand the role of device mapper in the working of LVM. Can someone please explain. If LVM metadata contains configuration details of volume groups, and it knows which physical disk to write to, doesn't it work like linux normal partition. What does LVM use device mapper for ? And is device mapper something that can be avoided while using LVM ?

No. AFAIK device mapper is required by LVM. Being a kernel driver, it's at a lower level than LVM. LVM doesn't speak to hardware directly, but via DM. This abstraction level allows you e.g. to use LVM on top of a software RAID provided by DM.

From the Wikipedia article:

Yea, true. LVM cannot speak directly to hardware, but via DM.
But so is the case with normal partitions too.
The request goes to hardware via device drivers, just like any other hardware requests.
What does device mapper do, which device drivers cant ?

device-mapper is responsible for mapping blocks in a block device(s) into a virtual block device: much like the virtual memory system maps pages of physical memory into a virtual address space.

So, if stored on disk you have:
AB........CD.........E.....F...
where each character represents a block of data.
Device mapper can make it look like a single contiguous block device, i.e.
ABCDEF even when those blocks are spread across multiple devices.

lvm metadata is used to tell device-mapper which blocks will make up a given logical volume, but it's device-mapper that is doing the actual work of mapping them.

lvdisplay --maps or lvs --segments are good commands for seeing how the blocks of your lv are actually organised on disk.

Why not just do that in the device driver? The answer is that dev-mapper is an abstraction layer. The backing devices underneath it don't even have to be of the same type.

Hope that helps.

Historically, LVM1 in Linux 2.4.x didn't require DM. It provided its own kernel module, lvm-mod, instead. The LVM we have now is LVM2, and it does require DM to interface with the kernel.

DM is not used exclusively by LVM though. Once upon a time, there was a competing volume manager, EVMS, that also used the DM interface. DM allowed them to re-use much of the common infrastructure. Nowadays, it's used e.g. by Stratis. Beside volume management, DM has many other applications. It is used for software RAID, disk encryption, DM multipath, data integrity protection, etc. Rather than re-implementing the same functions in a separate driver for each task, they all make use of DM facilities.

If you're interested to know what exactly DM does, here is a good description. The RHEL 7 LVM Administration guide has even more details on it. And here is how DM and LVM2 started to be.

1 members found this post helpful.

Erk - I remember the original LVM1. It's a wonder it ever progressed to an accepted tool - especially at such a critical point in the I/O stack.

DM is a kernel-level block device driver which communicates with other block device drivers to actually perform the I/O.

The analogy with "virtual memory" is actually a very good one.

And really, all it is doing is setting up the same type of map that the kernel uses, for example, to map offsets within a partition to actual major and minor device numbers and LBAs. It's using ONE mapping mechanism to perform the magic needed for a variety of features.

When you talk to "an LVM volume group," you talk to the mapper. The mapper then segregates your request into appropriate physical I/O requests which are sent by the mapper to the devices. The results are then reassembled if necessary and returned to you. This is the technology that maintains the LVM illusion.