Re: [PATCH 0/3] scsi_dh: Make scsi device handler modules automatically inserted

[Chandra Seetharaman <sekharan@us.ibm.com>]

James,

Any updates on this ?

thanks

chandra
On Fri, 2009-06-19 at 12:37 -0700, Chandra Seetharaman wrote:
> Hi James,
> 
> Thanks for getting back on this.
> 
> On Thu, 2009-06-18 at 17:48 -0500, James Bottomley wrote:
> 
> > > 
> > > Was there ever any followup to this?
> > 
> > OK, since I've forgotten where we are, let me summarise what I think the
> > situation is (correct me if I misstate any of the facts):
> > 
> > This code adds no functional value to the kernel because dm already
> > autoloads the correct handlers based on the inquiry strings
> 
> First point of clarification:
> 
> The main purpose of moving the device handlers from the dm-layer to scsi
> layer was that the time at which dm-layer comes in is too late.
> 
> SCSI-DH was added mainly to make sure that scsi layer recognize that
> these are special devices and has to be handled differently.
> 
> (Original problem was that during device probing lot of ios are sent to
> passive paths which caused boot time delays and tons of errors messages.
> These increase linearly with the number of luns and the number of
> passive paths, i.e more redundant the system is, more time it takes to
> boot and more error messages it spits out).
> 
> To paraphrase, if we were willing to wait till dm layer loads
> appropriate device handler modules, there would be no need for us to
> move the device handlers to SCSI layer.
> 
> With that clarification....
> 
> Having device handlers in SCSI is useful _only_ if we have the
> appropriate device handler modules in initrd. Otherwise, the user will
> go thru all the sufferings (boot delay and error messages) that they
> went thru when the device handlers were in dm-layer voiding the very
> benefit of moving the handlers to SCSI layer.
> 
> As of today (actually since scsi dh was in the kernel), I suggest the
> users of scsi device handler modules to create a new initrd with the
> required scsi_dh module
> (http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide#head-fb3efbb82fa69ca86b7db26423c235ae6c280caa)
> 
> Ideal way to solve this problem is to make sure the
> appropriate/necessary modules are built into the initrd image
> automatically (as is the case with all other devices that need a
> driver), without the user/admin doing it .
> 
> Hence this patch.
> > 
> > The only value it adds is that by overloading the module table with the
> > inquiry strings, mkinitrd pulls in the correct dm handlers for the state
> > the system was in.
> > 
> > the unaddressed problems are:
> > 
> > The kernel now tries to load the dm handler for the device dynamically
> > whether or not the user is actually deploying multi-path (previously dm
> > does this and if it's not loaded, that doesn't happen).  It's entirely
> > unclear whether this would interfere with proprietary multipath handlers
> > or even cause problems in single path systems which were designed that
> > way.
> 
> This is by design (of SCSI DH). We do want the device to be attached to
> its handler _irrespective_ of whether multipath comes along or not.
> 
> BTW, there is _no_ infrastructure in multipath for handlers. They were
> removed from multipath when scsi dh came along. So, no worries about
> proprietary multipath handlers. Also, multipath _can_ attach a device to
> a different (SCSI) device handler if it finds that the one that is
> already attached is not the right one.
> 
> SCSI DH is implemented to make accessing the devices better (as is the
> case with any device specific driver over generic one). So, the effect
> of scsi dh handler on single path system is towards betterment
> than being problematic.
> 
> > So as I see it, the functional benefit to a running kernel is zero and
> > the functional risk exists but is unquantified, so it seems far better
> > simply to solve this issue in mkinitrd.
> 
> I do not agree. This functionality makes the scsi devices behave the
> same way as the other devices, and hence make the system admin's life
> easier.
> 
> I hope you consider this feature in a better light now :)
> 
> chandra
> > 
> > James
> > 
> >