[dm-devel] [PATCH] multipath-tools: remove hwhandler when it's alua

[Xose Vazquez Perez]

On 10/12/2016 06:20 PM, Benjamin Marzinski wrote:

> On Wed, Oct 12, 2016 at 01:06:10PM +0200, Xose Vazquez Perez wrote:

>> RDAC devices also depend *exclusively* on "retain_attached_hw_handler"
>> and "detect_prio" to run in ALUA mode.

> The purpose of the the "retain_attached_hw_handler" and "detect_prio"
> options were to allow devices that support ALUA and non-ALUA modes, to
> detect which mode the device was in, so that the builtin configuration
> would work correctly for both modes.

Then that is validating my point, hwhandler="1 alua" is superfluous.
Because it's autodetected and autoconfigured from the array, first from
the kernel and later from multipath-tools.

> If a device is ALUA only, I don't see any benefit to not hardcoding
> that.  Simply from a ease-of-use persepective, having ALUA in the
> configuration make it obvious how the device is supposed to be
> configured.

It's redundant having RETAIN_HWHANDLER_ON and hwhandler="1 alua" defined.

>  But more importantly, as has already been metioned, it's
> more robust to hardcode the ALUA handler for the devices that need it in
> case the handler was not attached before multipath started working on
> the device.

Why you do not trust the SCSI subsystem? It seems a bit paranoid.
Anyway, if you are really uncomfortable with the change, this patch
should be dropped.

> Also, if I recall correctly, for the device handler to get
> attached correctly, we don't just need the device handler module
> isntalled before multipathd starts. We need it installed when the path
> device is initially discovered.

This is a kernel modules dependency bug. Distributions can bypass it
by including these modules in the initrd image.

> The more I think about this, the more I think we might want to revisit
> some to the configuration simplifications that have been made.

Could you please review all commits?
git log -p --reverse --since="Mon Jun 13 16:38:50 2016" libmultipath/hwtable.c
What should be removed?

> In some cases, I think they went too far. For instance, most devices will work
> correctly regardless of the values for things like "rr_minio_rq" and
> "path_selector", so I have no objection to these values being removed
> from the device configuartion, if they are the same as the default
> values.  On the other hand, we have things like "hardware_handler" and
> "path_checker", where the device simply will not function correctly with
> certain values.  For these attributes, it makes sense to leave them in
> the device configuration, even if they are the same as the default
> values.

Related to path_checker, only two changes were done:
6019c4e0 replace TUR by RDAC in two RDAC devices
40fd537c replace DIRECTIO by TUR(default)

Related to hardware_handler, no relevant changes were done.

> The goal should be that you can't break any device
> configurations by changing the default values.

It is going to be too verbose, you should send a patch to prove your thoughts.

Thank you.