Hi Ben,
On Thu, 15 Nov 2007 13:24:28 -0600, Benjamin Marzinski <bmarzins@xxxxxxxxxx> wrote:
> On Wed, Nov 14, 2007 at 03:44:56PM -0500, Kiyoshi Ueda wrote:
> >
> > Why do you need to separate the first stage and the second stage?
> > I don't think we need to separate them.
> > I think the point is whether execute getuid callout or not.
> > So we should need just 2 stages like below:
> > (The keyword "pre_getuid_filter" is not so good, just a example.)
> >
> > ----------------------- /etc/multipath.conf -------------------------
> > # First stage filter. Drop unneeded devices on this stage
> > pre_getuid_filter {
> > whitelist_driver "scsi|cciss"
> > whitelist_device {
> > vendor "IBM"
> > model "S/390 DASD ECKD"
> > }
> > blacklist_driver "*"
> > }
> >
> > # Second stage filter
> > filter {
> > blacklist_devnode "sda"
> > whitelist_wwid "012345"
> > blacklist_wwid "*"
> > # only wwid filter may be enough in this stage
> > }
> > ---------------------------------------------------------------------
> >
> > ---------------------------- multipathd -----------------------------
> > for_each_devnode in /sys/block {
> > o gather all sysfs information including vendor and model
> > o decide whether it is needed using the first stage filter
> > (the matching rule is that first match is used)
> > o store it in pathvec if needed
> > }
> >
> > for_each_remained_devnode in pathvec {
> > o run getuid callout
> > o decide whether it should be used for map by the second stage filter
> > (the matching rule is that first match is used)
> > }
> > ---------------------------------------------------------------------
> >
> > What do you think?
>
> This method has a lot going for it. I like the ability to override the
> default blacklisted drivers, even if it's almost never used, which you
> couldn't do with an "invalid_drivers" section. I also like the finer
> granularity on which devices to run the getuid callout on.
>
> 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 it's no problem because of the reason below.
It depends on subsystem type whether vendor/model information exist
in sysfs or not.
Multipath-tools already has sysfs scanners for each subsystem type
(e.g. scsi_sysfs_pathinfo, ccw_sysfs_pathinfo, cciss_sysfs_pathinfo).
When there is no vendor/model information, each scanner can make
appropriate decision: for example,
- scsi scanner will take it as error and drop the device
- cciss scanner won't care about it and use the device
After that, devices without vendor/model information don't match
any "device" rules, either blacklist nor whitelist.
They can match other rules like "devnode" and "driver".
Thanks,
Kiyoshi Ueda
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
