[dm-devel] Can we drop 'hardware_handler "1 alua"'?

[Benjamin Marzinski]

On Tue, Mar 27, 2018 at 10:56:29AM +0200, Martin Wilck wrote:
> hwtable.c has multiple entries that set 'hardware_handler "1 alua"'
> explicitly. But the kernel has been auto-attaching the ALUA hwhandler
> to devices that support it since 4.3, the only prerequisite being that
> scsi_dh_alua is present at device probing time (kernel commits
> d95dbff2, d6a32b98). "retain_attached_hwhandler" is also hard-wired
> since 4.3. Thus if the above prerequisite is met, there's no point in
> setting 'hardware_handler "1 alua"'.
> 
> We've recently seen problems with the explicit setting of the alua
> hwhandler in the hwtable; if we do this and the device fails ALUA for
> whatever reason, setting up the multipath map fails entirely.
> 
> Therefore we have reasons to try and remove 'hardware_handler "1 alua"'
> from the hwtable. But it could cause regressions in some cases, e.g.
> for distributions that don't force-load scsi_dh_alua before device
> probing, or for kernels older than 4.3.
> 

If the only mode of operation a device supports is alua, and something
fails there, the device may well not be usable. If we can't send the
alua commands that the device needs, we definitely shouldn't just be
silently failing back to something broken. I do agree that any device
that has multiple modes that it can be configured in (or at least
devices that could be configured as ALUA or something else, where we
can't tell from the vendor/product/revision) should have their default
config set to the other mode, since multipath should autodetect if they
are in alua mode. If autodetection isn't working for some devices, we
should fix that.

-Ben

> Opinions, please.
> 
> Martin
> 
> -- 
> Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)