On Thu, Nov 03 2011 at 10:47am -0400, Moger, Babu <Babu.Moger@xxxxxxxxxx> wrote: > > -----Original Message----- > > From: Mike Snitzer [mailto:snitzer@xxxxxxxxxx] > > Sent: Wednesday, November 02, 2011 10:46 AM > > To: device-mapper development > > Cc: Linux SCSI Mailing list > > Subject: Re: [PATCH 3/4] scsi_dh_rdac: Adding the match > > function for rdac device handler > > > > On Wed, Nov 02 2011 at 11:23am -0400, > > Moger, Babu <Babu.Moger@xxxxxxxxxx> wrote: > > > > > > OK. I will add the check for TPGS. I will send the patches tomorrow. > > > For sending the VPD pages(0xC2, 0xC4 and 0xC8), I think we need be > > little careful here. > > > This includes sending these commands to every possible device in the > > system. That is what we want to avoid. > > > I will investigate more on that. That will be my next set of patches > > independent of this. > > > > Much appreciated. I agree with Hannes, ideally we wouldn't need the > > rdac dev_list. > > Yes, We would like to remove the dependency on Vendor/product strings. > I will work on that. These current patches will address the current the > Attach issue which I mentioned in the description(PATCH 0/4). > I will resubmit the patches now.. Great. > > What about the issue where the appropriate scsi_dh isn't attached > > during > > scan (resulting in boot failures, trespasses, etc)? > > > > Hannes, I know you had plans for how to address the early scsi_dh > > attachment (and this match() work is a great step forward). I just > > wanted to touch base with you on what your current vision is on how to > > achieve proper early scsi_dh attachment (and what the remaining TODO > > is). > > I am not aware of any other issue at this point. Hannes may know about it. Yeap Hannes is aware. I was referring to IO being issued to passive paths (ghost LUNs) because scsi_dh isn't yet loaded. Whereby causing the storage backend to trespass unnecessarily. This bouncing (and corresponding IO errors) are avoided if the appropriate scsi_dh module is always loaded before the storage driver (e.g. lpfc or qla2xxx). -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
