Thanks Hannes and Chandra for your patches and feedback. Right now we are internally discussing the pros and cons of both these approaches. We will respond to all your question once we arrive at the conclusion. Also adding our Team (Bob Stankey, Sudhir, Yanling, Vijay ) in the response. Thanks Babu Moger > -----Original Message----- > From: Hannes Reinecke [mailto:hare@xxxxxxx] > Sent: Tuesday, October 06, 2009 3:08 AM > To: sekharan@xxxxxxxxxxxxxxxxxx > Cc: linux-scsi@xxxxxxxxxxxxxxx; dm-devel@xxxxxxxxxx; Moger, Babu; > michaelc@xxxxxxxxxxx; Benoit_Arthur@xxxxxxx; > Eddie.Williams@xxxxxxxxxxxx; berthiaume_wayne@xxxxxxx > Subject: Re: [PATCH 0/4] scsi_dh: Make scsi_dh_activate asynchronous > > Chandra Seetharaman wrote: > > On Mon, 2009-10-05 at 15:01 +0200, Hannes Reinecke wrote: > > > > Thanks for the comment and the patch. I will try the patch. > > > >> Hmm. IIRC we added the synchronous mode by request of LSI/IBM, as > the RDAC > >> handler could only support on MODE SELECT command at a time. > >> If LSI checked this, okay, no objections. > > > > The original patch (for rdac) came from LSI (Moger Babu), I made > changes > > to the infrastructure and to the code to fit them together. > > > >> However: The main reason why we're getting flooded with MODE SELECT > commands > >> is that the RDAC handler switches _each LUN_, not the entire > controller. > >> Seeing that the controller simply cannot cope with the resulting > MODE SELECT > >> flood wouldn't it be more sensible to switch the entire controller > here? > > > > I see your point of view.... but here is the rationale... > > > > When we originally added the rdac support (as dm_rdac), we decided > this > > way consciously for the following reasons: > > 1. we do not know which link is broken (hba-ctlr or ctlr-lun). > > The way it is currently implemented, both these cases are > handled. > Quite. But if the ctlr-lun link is broken, we really should receive > and appropriate error code, which then could be handled in dm-rdac > appropriately. After all, the controller is still accessible and > so we don't have to guess what happened (which is all what multipath > is about). So I doubt we need to worry about this. > > > 2. multipath layer to decide what to do and this module to just do > > what it was told. > Yep. > > > 3. since multipath sends pg_init only if there is any IO sent to the > > lun, (with the current implementation) we don't have to change > > ownership (back and forth) of all the luns if the user is using > only > > a handful. > Well, yes. But if the implementation is such that changing ownership > for all LUNs is about as efficient as changing an individual LUN (or, > as the case might be, as _inefficient_ :-), surely it's better to > save us some coding here. > > > 4. to be consistent with LSI's original driver (which does one lun > at a > > time). > :-/ That's unfair. > But it still has the drawback that it doesn't scale; given enough LUNs > and > access patterns you _inevitably_ have to send MODE SELECT commands for > each LUN, ie you only delay this issue. > Only by switching all LUNs you can avoid this. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > hare@xxxxxxx +49 911 74053 688 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Markus Rex, HRB 16746 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
