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

[Moger, Babu]

> -----Original Message-----
> From: Mike Snitzer [mailto:snitzer at redhat.com]
> Sent: Wednesday, November 16, 2011 11:33 AM
> To: Moger, Babu; hare at suse.de
> Cc: Linux SCSI Mailing list; device-mapper development; Peter Jones
> Subject: Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for
> rdac device handler
> 
> On Thu, Nov 03 2011 at 11:17am -0400,
> Mike Snitzer <snitzer at redhat.com> wrote:
> 
> > On Thu, Nov 03 2011 at 10:47am -0400,
> > Moger, Babu <Babu.Moger at netapp.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Mike Snitzer [mailto:snitzer at redhat.com]
> > > > 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
> 
> ...
> 
> > > > 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).
> 
> I have reviewed the scsi_dh match() changes (those from Hannes that are
> already upstream and the 4 patches from Babu to complete match() for
> other device handlers and the scsi_dh cleanup).
> 
> Hannes, in your cover-letter from the original scsi_dh_alua match
> patchset, here: http://www.spinics.net/lists/linux-scsi/msg54281.html,
> you said:
> 
> "In contrast to what we've discussed at LinuxTag I have not tried
> to attach the alua device handler directly from scsi_scan.
> Reason is that I need to issue SCSI commands during activation,
> which means I would have to attach it from near the end of
> scsi_add_lun(), at which point the device_handler would be attached
> via the current method anyway. So I fail to see the gain here."
> 
> I haven't picked through the scsi_dh/scsi code enough to know what "the
> current method" is (but I'm reviewing the code now).  That said, a
> quick
> recap of what you feel the relevant highlights are would be
> appreciated.
> 
> But I thought the issue we discussed at LinuxTag was: how do we
> autoload
> the scsi_dh module(s) so that the device handler is even available for
> attachment?
> 
> 
> Babu, you said that your patchset to implement match() for rdac
> resolved
> the problem of the device handler not attaching properly:
> http://www.redhat.com/archives/dm-devel/2011-November/msg00032.html
> 
> But that is only the case if scsi_dh_rdac has already been loaded early
> by the initramfs right?

That is correct. I had included  the handler in initramfs.

> 
> Given the updated scsi_dh match code: should it be safe for the
> initramfs to just load all scsi_dh modules (and ALUA will be preferred
> if TPGS is set)?

Yes, it would be great..

> 
> Does it make sense to re-visit Peter Jones' modalias code to autoload
> scsi_dh in kernel rather than relying on adhoc initramfs code to know
> to
> load the modules?

I don’t have complete understanding that. Can't comment.

> 
> Mike