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 > > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
