[dm-devel] Can we drop 'hardware_handler "1 alua"'?
Martin Wilck
mwilck at suse.com
Tue Mar 27 19:39:32 UTC 2018
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 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)
More information about the dm-devel
mailing list