[dm-devel] [PATCH] kpartx: Add -P option for partition scanning

[Benjamin Marzinski]

On Tue, Feb 22, 2022 at 10:16:35PM +0000, Ritika Srivastava wrote:
> Ben,
> 
> Thank you for reviewing this.
> 
> On 2/22/22, 11:32 AM, "Benjamin Marzinski" wrote:
> 
>    > And I'm trying to figure out why you want to create /dev/loop0p1 if you
>    > already have /dev/mapper/loop0p1?  The ability of kpartx to create
>    > partitioned loop devices predates the existance "kpartx -P". So perhaps
>    > the better question is, why do you want to run
> 
>    > # kpartx -av test.img
> 
>    > instead of just running
> 
>    > # loasetup -fP test.img
> 
>    > They both get you partition devices, and you don't need both of them.
>    > Or do you, for some reason I don't understand?
> 
> My previous update may not have been clear regarding the supporting use case behind this patch.
> It highlighted what the -P option would add to kpartx.
> 
> The idea is to avoid having both /dev/loop0p1 and /dev/mapper/loop0p1 and support the following use case - 
> After detaching via kpartx -d, /dev/loop0p1 is still present which on subsequent kpartx -a operation results in both /dev/loop0p1 and /dev/mapper/loop0p1 being present.
> 
> Yes, you are right, workaround could be to use losetup -P the first time around when creating the loop device.
> Though, having this functionality within kpartx would be nice since kpartx is also used extensively.

So unless I'm missing something, we'd only really want this for removing
a kpartx device, in the case where somehow you have /dev/loopXpY
partitions without the LO_FLAGS_PARTSCAN flag set on the disk. That
seems like it shouldn't happen in the first place.  Obviously, you
showed that it can with parted.  But I would argue that this is a bug in
parted.  If parted is creating partitions, it should set
LO_FLAGS_PARTSCAN so the partition nodes get cleaned up.

I suppose kpartx could check if there are partition devices for the loop
device, and if so, it could set LO_FLAGS_PARTSCAN before doing the
remove. But setting it unilaterally would just cause it to create an
extra set of devices that would only serve to confuse people (and lvm).

Also, the actual partition /dev/loopXpY will always get removed. It's
just the devnode that stays around, and that won't confuse lvm. This
isn't that odd for loop devices. The /dev/loopX devnodes will stay
around once you're done with them, regardless of whether you create the
loop device will kpartx or losetup.


> 
> // workaround - losetup -P
> # kpartx -a -v test.img
> # ls -l /dev/loop0*
> brw-rw----. 1 root disk  7,   0 Feb 22 20:05 /dev/loop0
> 
> # parted -a none -s /dev/loop0 mkpart primary 64s 100000s
> # parted -a none -s /dev/loop0 set 1 lvm on
> # kpartx -d test.img  
> # ls -l /dev/loop0*
> brw-rw----. 1 root disk   7,   0 Feb 22 20:05 /dev/loop0
> brw-rw----. 1 root disk 259,   0 Feb 22 20:05 /dev/loop0p1
> 
> # kpartx -av test.img
> # ls -l /dev/mapper/loop0*
> lrwxrwxrwx. 1 root root       7 Feb 22 20:53 loop0p1 -> ../dm-2
> 
> # pvcreate /dev/mapper/loop0p1
> # pvscan
>   WARNING: Not using device /dev/loop0p1 for PV <UUID>.
>   WARNING: PV <UUID> prefers device /dev/mapper/loop0p1 because device is in dm subsystem.

So this example shows exactly why I don't want both /dev/loopXpY and
/dev/mapper/loopXpY. Whenever we use your -P option we can run into
this situation, right?

Martin, do you have any feelings on this.

-Ben

> Thanks,
> Ritika
> 
>