> -----Original Message----- > From: Mike Snitzer [mailto:snitzer@xxxxxxxxxx] > Sent: Wednesday, November 16, 2011 11:33 AM > To: Moger, Babu; hare@xxxxxxx > 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@xxxxxxxxxx> wrote: > > > 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 > > ... > > > > > 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 -- 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
