Re: [PATCH RFC 2/2] implement transport scan callout for iscsi

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

 



On Wed, 2005-05-25 at 14:04 -0400, James Bottomley wrote:
> On Wed, 2005-05-25 at 11:18 -0400, Luben Tuikov wrote:
> > MC/S in iSCSI can be seen as a "wide port" in SAS.
> > 
> > That is, commands are ordered, nexus is the same, going to the same port,
> > etc, etc, etc.  MC/S, has nothing to do with multipathing, which sits above
> > the nexus level.  With MC/S the nexus is the same.
> 
> When I use the term "multi-pathing" I mean multiple virtual paths may be
> traversed to get a command from an application to a target device.
> Under that definition, dm-multipath, MC/S and even network bonding are
> all examples of multi-pathing.
> 
> The visibility of the coding is what I have an issue with.  bonding
> could be inherited invisibly from the network but MC/S has to be
> explicitly coded in the software initiator whereas dm-multipath is done
> above the driver: one code base for all multi-path implementations.
> 
> > MC/S is a good thing.
> 
> a) It's optional, so you can't rely on it.
> b) it requires explicit coding in the driver which is a big negative
> since you can't leverage our existing multi-path code (i.e. more bug
> prone)
> c) The feature set it provides to Linux is identical to the feature set
> that dm-multipath provides.
> 
> It's pointless to add support for an optional feature that provides no
> additional benefit (and its detrimental when the only addition is a
> potential negative impact to the code quality).

Those are very strong arguments against having MC/S implemented for the
software iSCSI initiator. Especially true is (a). Not that many targets
offers MC/S, since according to RFC it implies ERL=2.

Now, back to open-iscsi initiator business and its mainline acceptance.
We are going to met your requirement and will remove multi-connection
support before next patch-set submission. As Mike C. mentioned before,
it is fairly easy to do since the whole connection management resides in
user-space. Though it will exists as a kernel patches on our web site
(http://www.open-iscsi.org) for those who wonders.

Are there are some other requirements we need to met besides MC/S
removal ?

Thanks for the good explanation of your point of view!
Dima

> James
> 
> 

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