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

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 05/24/05 21:00, James Bottomley wrote:
> On Tue, 2005-05-24 at 20:25 -0400, open_iscsi wrote:
> 
>>The MC/S feature of iSCSI is not multi-pathing. Multi-pathing would be the 
>>use of multiple sessions to reach the same target. Generally the two 
>>sessions would use the same InitiatorName+ISID but use different Target 
>>Portal Groups at the target. In SCSI terms, it is the same initiator 
>>accessing different SCSI ports.
> 
> 
> Well, yes, every driver vendor with a multi-path solution in-driver that
> made a single presentation to the mid-layer has argued that one...

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.

MC/S is a good thing.

	Luben

P.S. As Eddy mentioned multipathing sits at a higher level, namely
at the session level, where you open a different session to a different
port (à la SCSI parlé).
 
> The bottom line is that implementation must be in-driver.  So every
> driver doing it this way has to have their own separate multi-path
> implementation.  Whether you call it FC/AL or MC/S (or any of the other
> buzz acronyms) it's still a driver implementation of pathing.
> 
> 
>>MC/S can be used to improve band width of a session without using 
>>multi-pathing and it belongs in the driver because it is hidden from the 
>>upper layers. Think of it like parallel wires, each carrying separate (but 
>>sequenced) commands in parallel.
> 
> 
> So far, no-one has been able to produce any figures to show that MC/S is
> significantly better than symmetric active dm-multipath to an iSCSI
> target, but if you have them, please publish them.
> 
> Hiding something from the upper layers which the upper layers could do
> equally well themselves is what's considered wrong: it adds code bloat
> with no tangible benefit.
> 
> James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html