Um. Mostly because I just thought up this idea to address the issues you
had with my first idea. I though it would be nice if multipath had a
clearly defined set of devices it didn't need to bother checking, and
then it would only need to look at the filter rules after all the path
information had been gathered. However, you are correct. Multipath can
just check the blacklist_driver rules at the beginning of the filter
section before gathering path information, and the rest of the rules
afterwards, to achieve the same effect. As a side note, blacklist_driver
should also allow the special string "*", which blacklists all devices.
Also, whitelist_driver rules don't make any sense.
I tried to avoid having multiple filter-defining sections but I must admit having everything in one section might be confusing as well. The problem is, that there are three stages at which a decission has to be made to continue or not. First by driver or node name (Kiyoshi has a valid argument there). Every match at this early stage prevents useless work. Whitelist rules for driver and devnode make sense if internal rules have to be reversed ( e.g. internal blacklist uses blacklist_driver "*").
Second stage is to check whether it makes sense to continue with a certain class of devices (from vendor, model). At this point I do not think it makes sense to look at the driver and devnode rules again.
And finally, if the UID information has been gathered, there would be the moment to check which of them should be used.
When the current code does the final filtering it goes again through all stacked filters and by that a whitelist for a devnode(range) cannot be limited by a wwid blacklist.
There are some minor issues that crop up, if we do away with
invalid_drivers.
Without the invalid_drivers section, the current default devnode
blacklist rules would turn into blacklist_driver rules that were
automatically appended to the beginning of the filter section. The
Not appended at the beginning, because that could never be changed by user-specified rules. Everything pre-defined would have to get appended after the user defined list.
users' inability to whitelist certain devices seems like it would be
less obvious in this situation than it would be if there was a specific
section for invalid devices. But this does seem to be a pretty minor
fault. As a side note, the product_blacklist rules would still need to
become blacklist_device rules that are appended to the end of the filter
section, so it is possible to override them.
Yes.
There is also the issue of how to keep multipath from doing anything.
Currently, you need to use
blacklist {
devnode "*"
}
to keep multipath from doing anything to your devices. Unfortunately, if
you use the following
blacklist {
wwid "*"
}
it doesn't keep multipath from touching your devices (for instance, the
getuid callout is still run on them), although customers might naively
think that it should. With invalid_drivers, it is obvious how to keep
multipath from touching the devices. Without it, you are forced to do
Not if devnode (and driver) rules are checked before the other rules.
filter {
blacklist_driver "*"
}
If I understand what your idea is, I'm not sure that it's what we want
to do. In my mind, any of the following filters should allow you to
create a multipath device for the device with the wwid "foo"
I admit my idea had a major flaw. It is just not compatible with the way device detection is run. It might turn out that the only thing that has to be changed is to change which filter rules are used at a certain point of the detection.
Decide which device to ignore at all:
- look at the whitelist entries for devnode (and driver), continue to check if found
- look at the blacklist entries for devnode (and driver), do not use if found
- no match, continue
Decide for which devices to call getuid:
- look at the whitelist entries for device, continue to check if found
- look at the blacklist entries for device, do not use if found
- no match, continue
Decide which UIDs should be used:
- look at the whitelist entries for wwid, use if found
- look at the blacklist entries for wwid, do not use if found
- no match, use device
Stefan
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
