[dm-devel] Multipath blacklist exceptions issues

[Stefan Bader]

The flaw in Christophe's approach that I see is, that it makes it hard to
see why a device is blacklisted or not. Because the filter checks group
black- and whitelist for each of the keywords. A user does not know which is
the internal sequence of checking.

The issue I see with doing this is it messes with the one of the reasons
> for having the blacklist_exceptions in the first place.

IBM asked for the ability to let customers do
>
> blacklist_exceptions {
>        device {
>                vendor  "IBM"
>                product "S/390.*"
>        }
> }
>
> So that they could undo the product_blacklist line in the
> "IBM:S/390 DASD ECKD" default device configuration.  With the method you


Yes,  without any exceptions it was impossible to get DASDs working without
an extra device section. And this required knowledge of the complete
required parameters. Which renders the internal hardware table useless.

propose, customers will be able to undo that blacklist line. However,
> they will either have to use an exception like the one above, which
> makes it impossible to then blacklist any of those devices, or they will
> have to use an exceptions like
>
> blacklist_exceptions {
>         wwid "foo"
>         wwid "bar"
>         wwid "xyzzy"
>         ...
> }
>
> To manually allow each device. If you have lots of devices, and you want
> almost but not all of them multipathed, you no longer have to freedom to
> simply blacklist the ones you don't want. With the original method, the
>
blacklist_exception simply makes it like the product_blacklist line
> didn't exist. I'm not sure how much of a bid deal this is.


I think this is a real nutshell. At least the device blacklist for DASDs was
not introduced because there is no UID callout but as an easy way to exclude
the devices by default (probably like the driver idea). This was required
because in most cases DASDs are not used for multipathing.
It would be sufficient, if wwid whitelisting could be used to enable some
DASD devices. The UID for them follows a certain scheme and together with
wwid being a regular expression, it would be an acceptable effort to do.

Another possible redesign, which can do even more complex filtering than
> my last method, does away with any need for product_blacklist lines, and
> also keeps all the filtering information in one place is to simply have
> a two top level sections in the config file, "invalid_drivers" and
> "filter"
>
> invalid_drivers {
>         driver "string"
> }
>
> filter {
>         blacklist_driver "string"
>         blacklist_wwid "regexp"
>         blacklist_device {
>                 vendor "regexp"
>                 product "regexp"
>         }
>         whitelist_driver "string"
>         whitelist_wwid "regexp"
>         whitelist_device {
>                 vendor "regexp"
>                 product "regexp"
>         }
> }


I do not understand why the invalid_driver section is required. Would it not
be the same as putting blacklist_driver entries at the beginning of the
filter section? Otherwise I like that idea because it clearly defines the
sequence of filtering visible to the user.

devices whose driver matches a rule in "invalid_drivers" are totally
> ignored by multipath.
>
> In the "filter" section, the blacklist_* rules blacklist devices just
> like you would expect, and the whitelist_* rules whitelist them.  The
> important thing is that the rules are checked in order, and the first
> one to match is used.  The existing "product_blacklist" lines just turn
> into "blacklist_device" lines that are checked after all the lines in
> multipath.conf. If a device doesn't match any rules, it's allowed.
>
> This works like the lvm.conf filter line, and makes it easy to either
> blacklist a group of devices and then whitelist a few of them, or
> whitelist a group devices which were blacklisted by default and then
> blacklist a few of them. The only downside is that, with this method,
> order suddenly matters. Hopefully a helpful comment in the config file
> will keep this from confusing people.
>

In some way order already mattered before. Just not visible to everybody. A
wwid blacklist entry could not blacklist a certain device for which the
device node was whitelisted. I think with the filter idea it would be
possible to get it all together: having an internal filter, the ability to
prevent accessing devices that do not work and also the ability to override
the internal filter if that is desired. Internal filter rules would just be
appended to the user specified list. The only trick might be that a caller
to filter function can specify which specific filters to use.
For example when deciding which devices from /sys/block should be processed
further, only the driver an devnode entries would be evaluated and the first
match is used. Later, if the device vendor and model are known the list of
remaining devices would be again filtered. This time by the device entries.
And finally, if there is a wwid known for each remaining device, filter
those that match a wwid entry.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20071111/c47dabb9/attachment.htm>