Re: Can we drop 'hardware_handler "1 alua"'?

[Martin Wilck <mwilck@suse.com>]

On Tue, 2018-03-27 at 17:46 +0200, Xose Vazquez Perez wrote:
> On 03/27/2018 10:56 AM, 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.
> 
> Remove it, and add info to README.alua or README.kernel-lower-4.4 ...
> 
> 
> systemd distributions are safe with this line from
> multipathd/multipathd.service:
> ExecStartPre=-/sbin/modprobe -a scsi_dh_alua scsi_dh_emc scsi_dh_rdac
> dm-multipath

No. That's sufficient if multipathd uses 'hardware_handler "1 alua"',
but it isn't otherwise. Here is why:

The kernel assigns a hardware handler

 a) when a device is probed, a match is found in the internal hwtable
in scsi_dh.c, and the the matched scsh_dh_... driver is loaded into the
kernel at that point in time (no module autoloading),
 b) when a dm_multipath device is set up requesting a hwhandler
explicitly (that would be the 'hardware_handler "1 alua"' case),
 c) when the user sets the handler by writing to the sysfs "dh_state"
attribute (doesn't matter here).

In particular, when a hwhandler module is loaded, the kernel does _not_
look through the list of already probed SCSI devices to see if it
matches any of them.

The ExecStartPre= line above is executed when multipathd is started,
which is usually after SCSI device probing, so a) doesn't apply. If we
don't have 'hardware_handler "1 alua"', b) doesn't apply, either.

To avoid this problem, distributions would need to modprobe the
scsi_dh_XXX drivers before the other SCSI modules.

Regards
Martin

> 
> 
> Gentoo, Alpine and Debian/Ubuntu should adapt their OpenRC/sysvinit
> scripts and
> also initrd, just in case.
> 
> 
> The last longterm-kernel<4.4, 3.16 will die in "Apr, 2020":
> https://www.kernel.org/category/releases.html
> 

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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel