Re: Multipath blacklist exceptions issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 10, 2007 at 02:17:45AM +0100, Christophe Varoqui wrote:
> 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.

Looks fine to me.

-Ben
 
> 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

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux