On Mon, 2024-11-04 at 17:55 +0100, Zdenek Kabelac wrote: > Dne 04. 11. 24 v 16:03 Martin Wilck napsal(a): > > 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 > > 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. > > Hi > > It's been more about the idea - that you can try to communicate some > protocol logic for 'libblkid' in some way - that will automatically > make sure blkid will not try to open device in these unwanted cases. > > It could be possibly something like: > > if DM device is 'mpath' && file /run/mpath/do_not_open_MPATH_UUID > exists > the this will be makeing libblkid think it's a device it should not > be opened. > > Then mpath tool is just manages present of this file - so this way > you > do not rely on works of any udev flag. We'd still need to manipulate these "flag" files through udev rules, and we'd have to make sure no stale such file remain in place. I don't see the advantage of this approach yet (for multipath). We are are already using this sort of "flag file" mechanism to communicate between udev rules and multipathd, where environment variables can't be used. Again, in the LVM case, certain devices are always "private" to LVM and it makes no sense to run blkid on them, not even manually. But that isn't the case for multipath. Martin
