On Mon, 2024-11-04 at 15:00 +0100, Zdenek Kabelac wrote:
> Dne 03. 11. 24 v 23:43 Martin Wilck napsal(a):
> > When multipath reloads a device or fails or restores a path, the
> > udev
> > rules disable LVM scanning, but since .DM_NOSCAN isn't set, blkid
> > is
> > still run on the device. When multipath devices that are set to
> > queue_if_no_path lose all their paths at close to the same time,
> > udev
>
>
> Hi
>
>
> There is worth to be mentioned - blkid has for a long time
> 'special' rule
> -built-in for LVM (and some other devices i.e. crypt...)
>
> So whenever lvm2 uses LVM-uuid-suffix with the '-suffix' in
> it's UUID -
> it's a private DM device which is never even opened by blkid. We
> would like to
> convert all remaining LV activations to use this logic for every
> 'private'
> device - since this logic is 'persistent' and survive even complete
> removal
> od udevdb. However it takes some time and also the backward
> compatibility is
> complicating things a lot.
>
> But all I say is - the relaing on any logic of the udev flags is
> always kind
> of problematic - and lvm2 does not depend on this fragile flagging
> too much.
Thanks for the hint. I think you're referring to libblkid's commit
20e1c3d ("libblkid: ignore private LVM devices"), which makes blkid
ignore devices with LVM UUIDs matching "LVM-.*-.*". I actually hadn't
been aware of this.
But note that multipath is overloading the .DM_NOSCAN flag here to tell
higher layers that blkid shouldn't be run in the first place if a
multipath map is in a certain state (we're reusing this flag, which was
originally created for LVM, in a similar but not identical case where
we want the blkid call to be skipped).
Unlike LVM, multipath has no way to set a UUID with special properties,
because multipath doesn't own any meta data on disk. In the case of
multipath, the .DM_NOSCAN property can, and will, change for a map
while its UUID remains constant. That's what this patch is about.
Thanks
Martin
