[dm-devel] [PATCH 2/2] dm mpath: attach scsi_dh during table resume

[Mike Snitzer]

On Thu, Apr 25 2013 at 10:50am -0400,
Mikulas Patocka <mpatocka at redhat.com> wrote:

> 
> 
> On Thu, 25 Apr 2013, Mike Snitzer wrote:
> 
> > On Thu, Apr 25 2013 at  9:48am -0400,
> > Mikulas Patocka <mpatocka at redhat.com> wrote:
> > 
> > > 
> > > 
> > > On Mon, 22 Apr 2013, Mike Snitzer wrote:
> > > 
> > > > I spoke with Hannes at LSF, to address the potential crashes in the
> > > > endio path (e.g. stpg_endio) we'd have to bump the scsi_dh_data kref
> > > > where appropriate (e.g. for ALUA kref_get in submit_stpg and kref_put in
> > > > stpg_endio).
> > > > 
> > > > But that is just the tip of the iceberg relative to scsi_dh lifetime.
> > > > Seems we've been playing it pretty fast and loose with scsi_dh issued
> > > > requests vs detach for quite some time.
> > > > 
> > > > I'm now inclined to not care about this issue.  Take away is: don't
> > > > switch the device handler (attach the correct one from the start).
> > > 
> > > I did a patch that disables device handler switching and it was NACKed by 
> > > Hannes. The problem that he pointed out was - when we load SCSI device 
> > > handler modules, they attach automatically to SCSI devices they think they 
> > > belong to. The user then can't set the desired device handler in multipath 
> > > configuration because a different handler is already attached.
> > 
> > The handler that is automatically attached _should_ be the correct
> > handler.  We now have the .match() hook for scsi_dh and it has made for
> > reliable scsi_dh attachment of the correct handler.
> 
> The EMC devices work with both ALUA and EMC handlers - so there is no one 
> "correct" handler, the correct handler is the one that the user specified 
> in multipath configuration.
> 
> > > So we need a functionality to change device handlers.
> > 
> > I really cannot think of a sequence where the scsi_dh .match() will
> > attach the incorrect handler.  This is why I added the
> > "retain_attached_hw_handler" feature to mpath (commit a58a935d5).
> 
> The automatic handler assigment can't change existing handler.
> 
> But if one handler was automatically selected and the user selects a 
> different handler in multipath configuration, the handler is changed.
> 
> > > (or maybe stop the scsi device handlers from attaching automatically, but 
> > > it would surely generate a lot of other regressions)
> > 
> > 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).