[dm-devel] Multipath blacklist exceptions issues

[Stefan Bader]

2007/11/15, Benjamin Marzinski <bmarzins at redhat.com>:
>
>
> > What do you think?
>
> On the other hand, I agree with Stefan that there will be issues with
> trying to gather the sysfs information for devices that just don't have
> it.  Like he said, you can ignore them, but I wonder if this might cause
> problems for the rare, but still possible, case where you expect that
> a device should properly provide all its sysfs information, but for some
> reason, you can't get it. In this case the device would most likely be
> silently ignored.  Obviously, we can provide the information if you run
> the commands with a higher verbosity.


I think this wouls be acceptable. I am not sure whether any useful device
that is used for multipathing is not required to provide a /sys/block/device
link and a vendor/model attributes there. As long as the reason for which a
device is dropped can be seen with a higher verbosity level this should be
fine.

The bigger issue I have is that there should be a way to tell multipath,
> "Don't do anything."  Many people have a multipath package installed on
> their systems that they don't even know about, and they don't want it to
> do anything.  Right now, if you have
>
> blacklist {
>         devnode ".*"
> }
>
> You pretty much get that behaviour. If anything on their system happens
> to run the multipath command, nothing much really happens.  With this
> method, your adding more things that multipath has to do before if
> realizes that it shouldn't be doing anything. Of course this could
> easily be solved by adding the parameter to the defaults section of
> multipath.conf.
>
> defaults {
>         disable yes
> }
>
> This would allow multipath to quit immediately after reading the config
> file, and it would seperate the choice to disable multipath from the
> blacklist setup.


Would it really hurt that much if multipath has to go through some devices
before doing nothing? I think it should not take that much time to go
through /sys/block and gather that initial information.

Regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20071115/099a7fdd/attachment.htm>