* Can we drop 'hardware_handler "1 alua"'? @ 2018-03-27 8:56 Martin Wilck 2018-03-27 15:09 ` Benjamin Marzinski 2018-03-27 15:46 ` Xose Vazquez Perez 0 siblings, 2 replies; 5+ messages in thread From: Martin Wilck @ 2018-03-27 8:56 UTC (permalink / raw) To: Christophe Varoqui; +Cc: dm-devel mailing list, Xose Vazquez Perez 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Can we drop 'hardware_handler "1 alua"'? 2018-03-27 8:56 Can we drop 'hardware_handler "1 alua"'? Martin Wilck @ 2018-03-27 15:09 ` Benjamin Marzinski 2018-03-27 16:01 ` Xose Vazquez Perez 2018-03-27 15:46 ` Xose Vazquez Perez 1 sibling, 1 reply; 5+ messages in thread From: Benjamin Marzinski @ 2018-03-27 15:09 UTC (permalink / raw) To: Martin Wilck; +Cc: dm-devel mailing list, Xose Vazquez Perez 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Can we drop 'hardware_handler "1 alua"'? 2018-03-27 15:09 ` Benjamin Marzinski @ 2018-03-27 16:01 ` Xose Vazquez Perez 0 siblings, 0 replies; 5+ messages in thread From: Xose Vazquez Perez @ 2018-03-27 16:01 UTC (permalink / raw) To: Benjamin Marzinski, Martin Wilck; +Cc: dm-devel mailing list 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... ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Can we drop 'hardware_handler "1 alua"'? 2018-03-27 8:56 Can we drop 'hardware_handler "1 alua"'? Martin Wilck 2018-03-27 15:09 ` Benjamin Marzinski @ 2018-03-27 15:46 ` Xose Vazquez Perez 2018-03-27 19:39 ` Martin Wilck 1 sibling, 1 reply; 5+ messages in thread From: Xose Vazquez Perez @ 2018-03-27 15:46 UTC (permalink / raw) To: Martin Wilck, Hannes Reinecke, Benjamin Marzinski, Christophe Varoqui, dm-devel mailing list, Leonardo Arena, Thomas Deutschmann, Lars Wendler, Ritesh Raj Sarraf, Vincent McIntyre, Julian Andres Klode, Michael Lass 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Can we drop 'hardware_handler "1 alua"'? 2018-03-27 15:46 ` Xose Vazquez Perez @ 2018-03-27 19:39 ` Martin Wilck 0 siblings, 0 replies; 5+ messages in thread From: Martin Wilck @ 2018-03-27 19:39 UTC (permalink / raw) To: Xose Vazquez Perez, Hannes Reinecke, Benjamin Marzinski, Christophe Varoqui, dm-devel mailing list, Leonardo Arena, Thomas Deutschmann, Lars Wendler, Ritesh Raj Sarraf, Vincent McIntyre, Julian Andres Klode, Michael Lass 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-03-27 19:39 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-27 8:56 Can we drop 'hardware_handler "1 alua"'? Martin Wilck 2018-03-27 15:09 ` Benjamin Marzinski 2018-03-27 16:01 ` Xose Vazquez Perez 2018-03-27 15:46 ` Xose Vazquez Perez 2018-03-27 19:39 ` Martin Wilck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox