On Wed, 2009-03-18 at 18:47 +0000, James Bottomley wrote: > On Tue, 2009-03-17 at 18:36 -0700, Chandra Seetharaman wrote: > > From: Peter Jones <pjones@xxxxxxxxxx> > > > > This patch allows the use of modaliases on scsi targets to correctly > > load scsi device handler modules when the devices are found. > > > > Signed-off-by: Peter Jones <pjones@xxxxxxxxxx> > > Signed-off-by: Chandra Seetharaman <sekharan@xxxxxxxxxx> > > I have to say this is a bit icky. > > overloading the modalias type like this produces several nasty effects: > > 1. You don't actually care about type for any of the scsi_dh > handlers, so they all have it as a useless extra field > 2. TYPE_ANY is a bogus (non SAM) definition ... I suppose it's > unlikely ever to clash, but you never know >From (1) and (2) are you suggesting _not_ to use the TYPE field for scsi_dh handlers ? > 3. scsi_dh handlers would now get loaded on *any* system ... > regardless of whether it's using multipathing or not ... that's > going to cause problems with other multi path solutions, I bet. Actually that is the intent. We _do_ want scsi_dh handlers to be loaded before multipath comes into picture. Basically we want the handlers to be available ASAP after the device is configured. The reason is: - These devices are active/passive, SCSI doesn't know about it and any I/O sent to SCSI will be sent down to the device, irrespective of the active/passive nature of the device in that path. When the device (path) is passive, I/O leads to time delay and extraneous error message (these are the two main reasons we moved the device handler code from dm-multipath layer to SCSI(scsi_dh)). With scsi_dh, I/O to the passive path will be short circuited in prep_fn() and errors are REQ_QUIET'd. Currently I suggest users to add these modules to their initrd to make them available ASAP (as described at http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide#head-fb3efbb82fa69ca86b7db26423c235ae6c280caa) If we have the support thru modalias, then appropriate modules will be included in initrd by the installer, thereby making it easier for the user. BTW, dm-multipath currently have code to insert appropriate modules if needed (if they are not already made available). > > Why not use a separately defined module alias for this ... and then > program udev to understand it and do the loading only if multipath is > actually present? I think we might have to add the INQUIRY strings to > the uenv for this, but it would be a much more elegant solution. > > 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