Can we drop 'hardware_handler "1 alua"'?

Can we drop 'hardware_handler "1 alua"'?

[Martin Wilck]

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.

Opinions, please.

Martin

-- 
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

Re: 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@suse.com>, Tel. +49 (0)911 74053 2107
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

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

[Xose Vazquez Perez]

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


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

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

[Xose Vazquez Perez]

On 03/27/2018 05:09 PM, Benjamin Marzinski wrote:

> 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.

They are only two of them: DGC and RDAC.

> If autodetection isn't working for some devices, we should fix that.

...if it can be done in multipath-tools/kernel, but if it's an array bug...

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

[Martin Wilck]

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