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@xxxxxxxx>, 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
