2007/11/15, Benjamin Marzinski <bmarzins@xxxxxxxxxx>:
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.
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
> 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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
