Re: device mapper mapping across reboot

[Jitendra <jkhasdev@gmail.com>]

On Mon, Mar 12, 2018 at 10:49:02AM +0100, Zdenek Kabelac wrote:
>Dne 10.3.2018 v 11:47 Jitendra napsal(a):
>>
>>
>>>lvm2 is exactly solving this problem as it maintains consistent
>>>'metadata' on every device - so upon reboot devices are discovered and
>>>from their metadata dm tables are actived/restored.
>>
>>Got it.
>>
>>>So  are you looking for recreation of all the lvm2 infrastructure for
>>>this relatively quite complex task ?
>>Not exactly, but I want to create mapper device created before the root and
>>other fs get mounted so that I can track I/Os in target.
>>
>>>Or you just want to 'create' DM after kernel is booted ?
>>dmsetup create with my target.
>>
>>>Or you even want to pass 'DM' table line on kernel boot option line -
>>>so even your boot device is a 'DM' device ?
>>
>>It is something exactly, I wanna to do.
>>
>>eg. I wrote a basic target as explained here
>>http://techgmm.blogspot.in/p/writing-your-own-device-mapper-target.html
>>
>>Now, to use this target (kernel module), I need to create mapper device as
>>echo 0 <size_of_device> basic_target /Path/to/your/device 0 |
>>dmsetup create my_basic_dm_device
>>
>>After creation of device as /dev/mapper/my_basic_dm_device for
>>/dev/sda, if I do I/O from
>>/dev/mapper/my_basic_dm_device, then all I/O goes through basic_target before it
>>hits to /dev/sda.
>>
>>Now, if system is booted and disk is offline then it is very easy to create
>>mapper device. But now let suppose I want to boot on
>>/dev/mapper/my_basic_dm_device instead of /dev/sda1 etc. then I have to create
>>mapper device even before it get switch root.
>>
>>This is same case for other disks as well. So there should be a way so that I
>>can use device mapper framework after reboot.
>
>Hi
>
>Well in general - that's why every distribution is using init ramdisk.
>
>This ramdisk is loaded from a small /boot partition together with kernel.
>As you can see - you simply always need something to boot from - you
>cannot load your kernel from "DM" device.

Got it.

>Once kernel is booted and 'ramdisk' is processed - you have plenty of
>time and lots of binaries there (typically with lvm2 built-in)  - so
>here you can safely activate your root volume being on dm device (even
>without lvm2 just by issuing couple 'dmsetup' commands)

This is something which I have tried in following steps.

1. First load my target driver(eg. my_custom_target) in initramfs (RHEL 7) using dracuf.
2. Now  my_custom_target will be available when initramfs get loaded.
3. Before the switch_root, I tried to run following command as,

	[root@localhost ~]# ls -l /usr/lib/systemd/system/initrd-switch-root.service
	-rw-r--r--. 1 root root 737 Mar 12 07:00 /usr/lib/systemd/system/initrd-switch-root.service

	In above file, I have added  dmsetup command to create
	/dev/mapper/my_device as,

	# we have to use "--force" here, otherwise systemd would umount /run
	ExecStart=/usr/bin/echo 0 24035328 my_custom_target /dev/sda 0|/usr/sbin/dmsetup create my_device
	ExecStart=/usr/bin/systemctl --no-block --force switch-root /sysroot
	KillMode=none

But it does not have any effect, after booting I could not see
/dev/mapper/my_device.


>I'm aware there is some  Android person who proposed some booting into
>DM without initramfs - i.e.
>
>https://www.redhat.com/archives/linux-lvm/2017-May/msg00055.html
>
>I'm not sure in which stage this patch is - likely still not upstream
>thought, but there was some progress around this.
I have looked into it. Since I am workig with older kernel version (3.10) so
these patches wont help although it has some really good pointers.

>Still it's worth to say -  not using ramdisk is pretty much bogus idea
>- you should always use ramdisk - otherwise you are missing lots of
>important tools i.e. for validation of filesystem  before it gets
>mounted - so whoever wants to use 'DM'  to mount  rootfs  without
>initramfs is doing something wrong.

This is exactly same understanding of mine as well, but I tried to create mapper
device using dmsetup but no luck.
>
>Anyway - since it's still unclear what is your actually work - it's
>really hard to give you proper advice here.

In my target driver, I am tracking each and every I/O and looking for offset and
length in each bio and doing some logging stuff.

---
Jitendra