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
