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

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

 



c) The feature set it provides to Linux is identical to the feature set
that dm-multipath provides.

There is a subtle difference and that has to do with sequencing the commands. If you have ORDERED commands and they arrive at the target out of order then they must be re-ordered at the target before presenting it to the SCSI layer. HOQ is in this arena too.


If the Queue Algorithm Modifier in the Control Mode Page is set to 0, then you also have to reorder the commands. The iSCSI target's reordering takes care of this too.

I'm sure you already know this, but if you get an abort task set at the MP layer, you will have to issue it on all paths for the simulated nexus. iSCSI MC/S takes care of this too. There may be some ordering rules here too but I can't remember.

There may be other reasons that I don't know which also require sequencing and the future may also have some requirements.

Eddy

----- Original Message ----- From: "James Bottomley" <James.Bottomley@xxxxxxxxxxxx>
To: "Luben Tuikov" <luben_tuikov@xxxxxxxxxxx>
Cc: "open_iscsi" <ESQuicksall_open_iscsi@xxxxxxxxxxx>; <open-iscsi@xxxxxxxxxxxxxxxx>; "Mike Christie" <michaelc@xxxxxxxxxxx>; "'SCSI Mailing List'" <linux-scsi@xxxxxxxxxxxxxxx>
Sent: Wednesday, May 25, 2005 2:04 PM
Subject: Re: [PATCH RFC 2/2] implement transport scan callout for iscsi




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



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