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

[Mike Snitzer]

On Wed, Nov 16 2011 at  5:10pm -0500,
Moger, Babu <Babu.Moger at netapp.com> wrote:

> > -----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.

Including it in initramfs isn't enough.  The initramfs needs to actively
load the scsi_dh module(s) very early to avoid errors resulting from
passive paths.

> > 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..

OK.  But ideally we'd have more intelligent autoload of the scsi_dh
modules.  Though it is definitely a nice impovement, thanks to the
match() work, that we can now load all the scsi_dh modules and not worry
about the wrong handler getting attached.

Makes for incremental improvement where tools like dracut can just
blindly load all of the scsi_dh modules that were included in the
initramfs.

> > 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.

I was referring to work Peter did that enables the ability to autoload
scsi_dh modules via modalias, see this patchset (which would obviously
need to be refreshed): http://pjones.fedorapeople.org/tpgs/

So the kernel would know how to load the appropriate scsi_dh and the
various distro initramfs wouldn't need to worry about blindly loading
all the scsi_dh modules.

Leading to a leaner kernel/boot for systems that don't need scsi_dh.

Mike