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