On Wed, 2009-07-08 at 11:53 -0400, berthiaume_wayne@xxxxxxx 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@xxxxxxxxxxxxxxx > [mailto:linux-scsi-owner@xxxxxxxxxxxxxxx] On Behalf Of Chandra > Seetharaman > Sent: Tuesday, July 07, 2009 3:37 PM > To: James Bottomley > Cc: Peter Jones; linux-scsi@xxxxxxxxxxxxxxx; michaelc@xxxxxxxxxxx; > hare@xxxxxxx > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
