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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
