On Wed, Nov 16 2011 at 5:10pm -0500, Moger, Babu <Babu.Moger@xxxxxxxxxx> wrote: > > -----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: [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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
