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

Chandra Seetharaman
2009-06-19T19:35:13Z

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