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

[Hannes Reinecke <hare@suse.de>]

On 04/25/2013 05:31 PM, Mike Snitzer wrote:
> On Thu, Apr 25 2013 at 10:50am -0400,
> Mikulas Patocka <mpatocka@redhat.com> wrote:
> 
>>
>>
>> On Thu, 25 Apr 2013, Mike Snitzer wrote:
>>
>>> On Thu, Apr 25 2013 at  9:48am -0400,
>>> Mikulas Patocka <mpatocka@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).
> 
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.

Plus some vendors / admins might prefer for whatever reasons
to continue to use the original mode.

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.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html