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