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.
Although the case here can be different if the device as such is supposed to
be a udev visible volume - as the blkid skipping might make the volume just
'invisible' as whole.
Regards
Zdenek
