RE: [PATCH 0/3] scsi_dh: Make scsi device handler modulesautomatically inserted

[Chandra Seetharaman <sekharan@us.ibm.com>]

On Wed, 2009-07-08 at 11:53 -0400, berthiaume_wayne@emc.com wrote:
> Hi Chandra.
> 
> 	I can speak for EMC PowerPath in that it is affect by DM if both
> are trying to control the same device. Another large multipathing
> solution that may be affected would be Symantec's DMP.

Wayne,

James's concern was, "what happens when the scsi hardware handler is
attached to the device _and_ powerpath is the multipathing solution (and
not DM)". (since we will be attaching the handler automatically - with
this feature).

Anyways, I do not think we can practically take care of _all_
out-of-tree solutions, so it doesn't really matter what the answer for
the above question is :)
 
> 
> Regards,
> Wayne. 
> 
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Chandra
> Seetharaman
> Sent: Tuesday, July 07, 2009 3:37 PM
> To: James Bottomley
> Cc: Peter Jones; linux-scsi@vger.kernel.org; michaelc@cs.wisc.edu;
> hare@suse.de
> Subject: Re: [PATCH 0/3] scsi_dh: Make scsi device handler
> modulesautomatically inserted
> 
> 
> On Tue, 2009-07-07 at 18:14 +0000, James Bottomley wrote:
> > On Tue, 2009-07-07 at 13:51 -0400, Peter Jones wrote:
> > > On 07/07/2009 01:12 PM, James Bottomley wrote:
> > > > On Fri, 2009-06-26 at 09:56 -0400, Peter Jones wrote:
> > > >> James, I think Chandra and I have responded to most if not all of
> your points, 
> > > >> and would appreciate your thoughts on what we've said.
> > > > 
> > > > Well, you didn't respond to the important one:
> > > > 
> > > > You're seeking to change the binding of these helpers from manual
> to
> > > > automatic.  This would mean that the modules are loaded in the
> single
> > > > controller case, for which they may not be wanted and also when
> some
> > > > multi path tool other than dm-mp is managing the device, in which
> case
> > > > they may actively interfere with operations.  Your basic
> contention is
> > > > that you "don't see any concern here".
> > > 
> > > I think Chandra addressed this in his reply to your previous email: 
> > 
> > I don't think so:
> > 
> > > [From him]
> > > > This is by design (of SCSI DH). We do want the device to be
> attached to
> > > > its handler _irrespective_ of whether multipath comes along or
> not.
> > > > 
> > > > BTW, there is _no_ infrastructure in multipath for handlers. They
> were
> > > > removed from multipath when scsi dh came along. So, no worries
> about
> > > > proprietary multipath handlers. Also, multipath _can_ attach a
> device to
> > > > a different (SCSI) device handler if it finds that the one that is
> > > > already attached is not the right one.
> > 
> > I want to know what happens when some multipath system other than
> dm-mp
> > tries to use a system with a device handler attached ... I don't see
> how
> > that addresses the issue at all. The device handlers, when they're
> > attached can alter sense and return code processing .. this has the
> > potential to interfere with how the other multipath code is expecting
> > things to happen
> 
> When I responded to your earlier email I thought you meant the
> interaction between dm-mp and the hardware handler ( and not other
> out-of-tree multipath solutions). My answer was in that context alone.
> 
> Yes, your conclusion is correct. There are few functionalities in the
> hardware handler interface that might affect the above layers (block and
> above). One is the prep_fn() function, second is the check_sense()
> function, and third is the activate() function.
> 
> Since scsi_dh is designed for dm-mp :). 
> 
> I do not know of all the out-of-tree multipath solutions and how they
> behave and at what layer they interact. In effect, I haven't tested
> hardware handler with other multipath solutions.
> 
> > 
> > If we have to get really concrete: what happens with something like
> > powerpath and scsi_dh_emc attached?
> > 
> 
> They _might_ be affected as mentioned above.
> 
> > > [From you again]
> > > > When I ask what testing you've done for either of these, the
> studied
> > > > silence eloquently illustrates "none". A policy change like this
> > > > can't be made without being incredibly sure we're not going to
> screw
> > > > up existing installations.
> > > 
> > > I'll let Chandra address this, as it is my understanding that he has
> > > hardware and has tested this code with it.
> > > 
> > > > The second point I made speaks to the technical ugliness of this:
> what
> > > > you're basically doing is open coding multiple binding for a
> device
> > > > handler specific case.  If you can persuade me the policy above is
> > > > correct, then technically all this should be done correctly via
> multiple
> > > > binding in the generic device core ... before this interface
> nastiness
> > > > you're constructing propagates outwards and becomes part of the
> user
> > > > ABI.
> > > 
> > > I'm willing to re-implement the functionality with a different
> mechanism
> > > if it has your blessing, if you can be specific about what it is you
> think
> > > would be better.  Obviously I'll hold off on that until we've come
> to some
> > > agreement about the other aspects.
> > 
> > Well, the two things aren't so dependent: this dh_state attribute that
> > hannes just NAK'd is precisely a binding attribute for your hand
> rolled
> 
> Just to clarify:
> 
> dh_state attribute is not added new, it was originally added by Hannes. 
> 
> I just fixed a problem to make it work as it is intended, and sent an
> explanation (about my fix) for Hannes to reconsider is NAK.
> 
> > multiple driver attachment, so actually getting generic device
> multiple
> > binding sorted out would help out regardless of what the final
> > attachment policy decision is.
> > 
> > James
> > 
> > 
> 
> --
> 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
>