Indeed the current situation is fishy. Ben pointed a true braino in the
code I introduced when restructuring the blacklist lib :
in _filter_path(), I test each _filter_*() for r!=0 , where I intented
to check for r>0.
r==0 implements : "exit on first blacklist or exception match".
r>0 implements : "exit on first blacklist match".
With this later behaviour I can set things like that for max safety and
efficiency :
blacklist {
devnode .*
device {
vendor .*
product .*
}
wwid .*
}
blacklist_exceptions {
devnode sd.*
device {
vendor IET.*
product .*
}
wwid "1646561646265.*"
}
or pragmatically :
blacklist {
devnode .*
wwid .*
}
blacklist_exceptions {
devnode sd.*
wwid "1646561646265.*"
}
Working that out, I also realized there may be another small
misbehaviour :
First, a little background on path discovery operations :
1) /sys/block parsing shows devnode names
2) devnode names examination shows device identification strings
3) these strings help us choose a getuid helper, which finally shows
wwids
Meaning we want the devnode blacklisting to prevail over device and
wwid, in case we know we don't have device strings available (loop, dm-,
raw, ...)
Similarily, we want the device blacklist to prevail over wwid, in case
we know we don't have getuid callout available. I have no example for
this case though, so it shouldn't be as important as the previous one.
Problem is we challenge _filter_device() after _filter_wwid().
This can be easily shufled around.
So, I submit this (attached) patch to your review.
regards,
cvaroqui
Le samedi 10 novembre 2007 à 00:20 +0100, Stefan Bader a écrit :
>
>
> Any thoughts on this? Good Idea? Worth doing?
>
> To be honest, I do not see the real simplification in that many
> changes. Spreading black- and/or white-lists over so many places seems
> rather confusion to me. I agree that using devnode names is not ideal
> for the reasons you mentioned. That was done mainly to have an
> internal blacklist of known devices that are known not to work.
> Potentially this could be a device type (= driver name?). But would
> this not also be possible as a new element of the blacklist? E.g.:
>
> blacklist {
> driver fd
> driver device-mapper
> ...
> }
>
> The problem with the current implementation, in my thinking, is that
> we have a dependency between two sections (blacklist and
> blacklist_exceptions) and the keywords within. Without reading any
> further
> documentation it seems awkward that it is not possible to blacklist
> device nodes and punch holes by certain wwid numbers. When I think
> about it, I guess (any other opinions welcome) that a exception is
> what is really intended to be used. So that should always have more
> priority than a blacklist. So if the filter finds a matching entry in
> the blacklist_exceptions section, the device should be used.
>
> So my proposal would be:
>
> 1. process the blacklist_exceptions (any match enables the device)
> 2. process the blacklist
> 3. any device dropping through is also used.
>
> Additionally I like the idea of a match-by-driver extension.
>
> Stefan
diff --git a/libmultipath/blacklist.c b/libmultipath/blacklist.c
index 9a058f7..6297516 100644
--- a/libmultipath/blacklist.c
+++ b/libmultipath/blacklist.c
@@ -297,16 +297,14 @@ _filter_path (struct config * conf, struct path * pp)
int r;
r = _filter_devnode(conf->blist_devnode, conf->elist_devnode,pp->dev);
- if (r)
- return r;
- r = _filter_wwid(conf->blist_wwid, conf->elist_wwid, pp->wwid);
- if (r)
+ if (r > 0)
return r;
r = _filter_device(conf->blist_device, conf->elist_device,
pp->vendor_id, pp->product_id);
- if (r)
+ if (r > 0)
return r;
- return 0;
+ r = _filter_wwid(conf->blist_wwid, conf->elist_wwid, pp->wwid);
+ return r;
}
int
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
