All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Luben Tuikov <luben_tuikov@adaptec.com>
Cc: open_iscsi <ESQuicksall_open_iscsi@Comcast.net>,
	open-iscsi@googlegroups.com, Mike Christie <michaelc@cs.wisc.edu>,
	'SCSI Mailing List' <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] implement transport scan callout for iscsi
Date: Wed, 25 May 2005 14:04:07 -0400	[thread overview]
Message-ID: <1117044247.5210.15.camel@mulgrave> (raw)
In-Reply-To: <4294972D.4030807@adaptec.com>

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

James



  reply	other threads:[~2005-05-25 18:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42936441.0b798bab.39a4.ffff9774SMTPIN_ADDED@mx.googlegroups.com>
2005-05-24 21:01 ` [PATCH RFC 2/2] implement transport scan callout for iscsi Mike Christie
2005-05-24 23:17   ` James Bottomley
2005-05-25  0:25     ` open_iscsi
2005-05-25  1:00       ` James Bottomley
2005-05-25  1:28         ` open_iscsi
2005-05-25  5:22           ` Dmitry Yusupov
2005-05-25 12:55             ` open_iscsi
2005-05-25 13:00           ` Ming Zhang
2005-05-25 13:08             ` open_iscsi
2005-05-25 15:18         ` Luben Tuikov
2005-05-25 18:04           ` James Bottomley [this message]
2005-05-25 18:32             ` Dmitry Yusupov
2005-05-25 19:42               ` James Bottomley
2005-05-26  1:38             ` open_iscsi
2005-05-25  2:20 open_iscsi
  -- strict thread matches above, loose matches on Subject: below --
2005-05-21 21:39 Mike Christie
2005-05-24 17:09 ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1117044247.5210.15.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=ESQuicksall_open_iscsi@Comcast.net \
    --cc=linux-scsi@vger.kernel.org \
    --cc=luben_tuikov@adaptec.com \
    --cc=michaelc@cs.wisc.edu \
    --cc=open-iscsi@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.