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

[Mike Snitzer]

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?

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)?

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?

Mike