Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: [dm-devel] [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).
--
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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux