[dm-devel] Multipath blacklist exceptions issues

[Stefan Bader]

>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20071114/7a12042c/attachment.htm>