Re: [PATCH 1/3] scsi_dh: Add modalias support for SCSI targets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux