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