On Fri, Apr 26 2013 at 2:05am -0400, Hannes Reinecke <hare@xxxxxxx> wrote: > On 04/25/2013 05:31 PM, Mike Snitzer wrote: > > On Thu, Apr 25 2013 at 10:50am -0400, > > Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > >> > >> > >> On Thu, 25 Apr 2013, Mike Snitzer wrote: > >> > >>> On Thu, Apr 25 2013 at 9:48am -0400, > >>> Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > >>> > >>>> > >>>> > >>>> On Mon, 22 Apr 2013, Mike Snitzer wrote: > >>> > >>> The need to support changing device handlers (via multipath table load) > >>> is overblown/historic. > >> > >> So - do you mean that we make "retain_attached_hw_handler" the default > >> option and don't allow the user to change existing device handler in > >> multipath configuration? > >> > >> That's what my patch did and it was NACKed by Hannes. The problem there is > >> that behavior depends on module loading order - if you activate multipath > >> with "EMC" option, it activates the EMC handler. If you load the ALUA > >> module and activate multipath with "EMC" option, it stays with the ALUA > >> handler. > > > > .match allows for correct scsi_dh selection in the decision of alua vs > > emc (alua has the tpgs bit set) -- but both scsi_dh modules must be > > loaded. > > > > If the incorrect handler is getting attached then it is either a bug in > > the .match method (for the handler that should've been attached) or the > > storage isn't configured how the user thought and they need to > > adjust/reconfigure to have it be like they expected. > > > > Either way we really _could_ impose not allowing the scsi_dh handler to > > be changed (by multipath) -- which is why I Acked your patch. There is > > always the scsi_dh sysfs interface to allow the user to change the > > scsi_dh (and possibly shoot themselves in the foot). > > > Always providing there _is_ a correct way. > For eg RDAC might run in ALUA mode, but this is by no means > exclusively; the original 'rdac' mode will work there, too. Just like the emc handler, rdac_match will prefer alua over rdac if tpgs is set. > Plus some vendors / admins might prefer for whatever reasons > to continue to use the original mode. So you're saying an admin should have the flexibility to use rdac if they know better? I don't disagree in principle but in practice providing that flexibility comes at a cost (e.g. potential for kernel crashes). > So I don't think there is a 'correct' hardware handler. > Only a preferred one. And the preference is set by the user, > not the installation. Hence it would be a bad idea to > disallow scsi_dh changes. Disallowing scsi_dh changes is more about avoiding the potential for crashes (which have been seen in testing). As such I think there is more risk of hitting a crash (very bad) than there is of an admin _really_ wanting to prefer the proprietary handler (rdac) over the standards based one (alua). So I'm in favor of disallowing scsi_dh changes via multipath (until if/when the potential for scsi_dh crashes is eliminated). dm-multipath really doesn't have a role in attaching a scsi_dh these days. Disallowing scsi_dh changes acknowledges that the underlying kernel support has improved and that admins should take notice (and multipath-tools should now default to 'retain_attached_hw_handler'). -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
