From 1d96eaaa0b5c290a710ebdef1833865178b85e1d Mon Sep 17 00:00:00 2001
From: Vladislav Bolkhovitin
Date: Wed, 29 Apr 2009 11:12:43 +0000
Subject: [PATCH] Cersions and web updated
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@811 d57e44dd-8a1f-0410-8b47-8ef2f437770f
---
iscsi-scst/ChangeLog | 6 ++++++
iscsi-scst/README | 4 ++--
iscsi-scst/README_in-tree | 2 +-
qla2x00t/qla2x00-target/ChangeLog | 6 ++++++
qla2x00t/qla2x00-target/README | 4 ++--
scst/ChangeLog | 6 ++++++
scst/README | 2 +-
usr/fileio/ChangeLog | 4 ++++
usr/fileio/README | 2 +-
www/mc_s.html | 35 +++++++++++++++----------------
10 files changed, 46 insertions(+), 25 deletions(-)
diff --git a/iscsi-scst/ChangeLog b/iscsi-scst/ChangeLog
index f1a91bcfb..fc2846cd4 100644
--- a/iscsi-scst/ChangeLog
+++ b/iscsi-scst/ChangeLog
@@ -1,3 +1,9 @@
+Summary of changes in iSCSI-SCST between versions 1.0.1 and 1.0.2
+-----------------------------------------------------------------
+
+ - Support bidirectional transfers added
+
+
Summary of changes in iSCSI-SCST between versions 1.0.0 and 1.0.1
-----------------------------------------------------------------
diff --git a/iscsi-scst/README b/iscsi-scst/README
index ce58ddff7..88558a815 100644
--- a/iscsi-scst/README
+++ b/iscsi-scst/README
@@ -1,7 +1,7 @@
iSCSI SCST target driver
========================
-Version 1.0.1, 27 April 2009
+Version 1.0.2, XX XXXXX 2009
----------------------------
This driver is a forked with all respects version of iSCSI Enterprise
@@ -21,7 +21,7 @@ simultaneously all the driver's modules and files were renamed:
* iscsi-target -> iscsi-scst
* iscsi-target.ko -> iscsi-scst.ko
-This version is compatible with SCST version 1.0.1 and higher.
+This version is compatible with SCST version 1.0.2 and higher.
Installation if your Linux kernel already has iSCSI-SCST built-in
diff --git a/iscsi-scst/README_in-tree b/iscsi-scst/README_in-tree
index 3171d2053..afe9fde0c 100644
--- a/iscsi-scst/README_in-tree
+++ b/iscsi-scst/README_in-tree
@@ -1,7 +1,7 @@
iSCSI SCST target driver
========================
-Version 1.0.1, 27 April 2009
+Version 1.0.2, XX XXXXX 2009
----------------------------
This driver is a forked with all respects version of iSCSI Enterprise
diff --git a/qla2x00t/qla2x00-target/ChangeLog b/qla2x00t/qla2x00-target/ChangeLog
index aa9de5b02..8f46cb8d4 100644
--- a/qla2x00t/qla2x00-target/ChangeLog
+++ b/qla2x00t/qla2x00-target/ChangeLog
@@ -1,3 +1,9 @@
+Summary of changes between versions 1.0.1 and 1.0.2
+---------------------------------------------------
+
+
+
+
Summary of changes between versions 1.0.0 and 1.0.1
---------------------------------------------------
diff --git a/qla2x00t/qla2x00-target/README b/qla2x00t/qla2x00-target/README
index 57ff30365..8cdfef755 100644
--- a/qla2x00t/qla2x00-target/README
+++ b/qla2x00t/qla2x00-target/README
@@ -1,7 +1,7 @@
Target driver for Qlogic 22xx/23xx Fibre Channel cards
======================================================
-Version 1.0.1, 27 April 2009
+Version 1.0.2, XX XXXXX 2009
----------------------------
This driver has all required features and looks to be quite stable (for
@@ -13,7 +13,7 @@ all necessary callbacks, but it's still capable to work as initiator
only. Mode, when a host acts as the initiator and the target
simultaneously, is supported as well.
-This version is compatible with SCST core version 1.0.1 and higher and
+This version is compatible with SCST core version 1.0.2 and higher and
Linux kernel 2.6.26 and higher. If you need to use this driver on
kernels prior 2.6.26, you should apply qla_ini_pre-2.6.26.patch.
diff --git a/scst/ChangeLog b/scst/ChangeLog
index b48ea37d0..7fe13f490 100644
--- a/scst/ChangeLog
+++ b/scst/ChangeLog
@@ -1,3 +1,9 @@
+Summary of changes between versions 1.0.1 and 1.0.2
+---------------------------------------------------
+
+ - Support bidirectional transfers added
+
+
Summary of changes between versions 1.0.0 and 1.0.1
---------------------------------------------------
diff --git a/scst/README b/scst/README
index d849bf5db..42e925b89 100644
--- a/scst/README
+++ b/scst/README
@@ -1,7 +1,7 @@
Generic SCSI target mid-level for Linux (SCST)
==============================================
-Version 1.0.1, 27 April 2009
+Version 1.0.2, XX XXXXX 2009
----------------------------
SCST is designed to provide unified, consistent interface between SCSI
diff --git a/usr/fileio/ChangeLog b/usr/fileio/ChangeLog
index 1815fdd01..e3a5c6a18 100644
--- a/usr/fileio/ChangeLog
+++ b/usr/fileio/ChangeLog
@@ -1,3 +1,7 @@
+Summary of changes between versions 1.0.1 and 1.0.2
+---------------------------------------------------
+
+
Summary of changes between versions 1.0.0 and 1.0.1
---------------------------------------------------
diff --git a/usr/fileio/README b/usr/fileio/README
index 76ffd8fcc..14a6dd9e2 100644
--- a/usr/fileio/README
+++ b/usr/fileio/README
@@ -1,7 +1,7 @@
User space FILEIO handler
=========================
-Version 1.0.1, 27 April 2009
+Version 1.0.2, XX XXXXX 2009
----------------------------
User space program fileio_tgt uses interface of SCST's scst_user dev
diff --git a/www/mc_s.html b/www/mc_s.html
index 4db442a4b..0123892db 100644
--- a/www/mc_s.html
+++ b/www/mc_s.html
@@ -54,9 +54,9 @@ being actively used, nor going to implement it in the future.
MC/S is done on the iSCSI level, while MPIO is done on the higher
level. Hence, all MPIO infrastructure is shared among all SCSI
-transports, including Fibre Channel and SAS.
+transports, including Fibre Channel, SAS, etc.
- MC/S was designed at time, when most OS'es didn't have OS level
+
MC/S was designed at time, when most OS'es didn't have standard OS level
multipath. Instead, each vendor had its own implementation, which
created huge interoperability problems. So, one of the goals of MC/S was
to address this issue and standardize the multipath area. But
@@ -85,9 +85,9 @@ Consequently, all reservations and other SCSI states as well as other
initiators connected to the device remain unaffected.
For MPIO failover recovery is much more complicated. This is because
-it involves transferring outstanding commands and SCSI states from one
+it involves transfer of all outstanding commands and SCSI states from one
I_T Nexus to another. The first thing, which initiator will do for
-failover recovery is to abort all outstanding commands on the faulted
+that is to abort all outstanding commands on the faulted
I_T Nexus. There are 2 approaches for that: CLEAR TASK SET and LUN RESET
task management functions.
@@ -105,7 +105,7 @@ RESET resets all SCSI settings for all connected initiators to the
initial state and, if device had reservation from any initiator, it will
be cleared.
-But the harm will be minimal:
+But the harm is minimal:
- With TAS bit set on Control Mode page, all the aborted commands will
@@ -131,12 +131,12 @@ retry all the aborted commands. On a properly configured system it
should be less than few seconds, which is well acceptable on practice.
If Linux storage stack improved to allow to abort all submitted to it
commands (currently only wait for their completion is possible), then
-time to abort all commands can be decreased to a fraction of second.
+time to abort all the commands can be decreased to a fraction of second.
Performance
At first, neither MC/S, nor MPIO can improve performance if there is
-only one SCSI command sent to target at time. For instance, for tape
+only one SCSI command sent to target at time. For instance, in case of tape
backup and restore. Both MC/S and MPIO work on the commands level, so
can't split data transfers for a single command over several links. Only
bonding can improve performance in this case, because it works on the
@@ -149,9 +149,9 @@ link was submitted earlier. Delays in links processing can change
commands order in the place where target receives them.
Since initiators usually send commands in the optimal for performance
-order, reordering can hurt performance. But this can happen only with
-naive implementation, which can't recover the optimal commands execution
-order. Currently Linux is not naive and quite good on it. See, for
+order, reordering can somehow hurt performance. But this can happen only with
+naive target implementation, which can't recover the optimal commands execution
+order. Currently Linux is not naive and quite good on this area. See, for
instance, section "SEQUENTIAL ACCESS OVER MPIO" in those measurements. Don't look at the absolute
numbers, look at %% of performance improvement using the second link.
@@ -161,11 +161,11 @@ possible maximum.
If free commands reorder is forbidden for a device, either
by use of ORDERED tag, or if the Queue Algorithm Modifier in the Control
Mode Page is set to 0, then MPIO will have to maintain commands order by
-sending them over only a single link. But on practice this case is
+sending commands over only a single link. But on practice this case is
really rare and 99.(9)% of OS'es and applications allow free commands
reorder and it is enabled by default.
-However strictly preserving commands order as MC/S does has a
+
From other side, strictly preserving commands order as MC/S does has a
downside as well. It can lead to so called "commands ordering
bottleneck", when newer commands have to wait before one or more older
commands get executed, although it would be better for performance to
@@ -201,14 +201,13 @@ for instance,
task? Better to spend this effort on improving MPIO. Simply, MC/S is
done on the wrong level. No surprise then that no Open Source OS'es
neither support, nor going to implement it. Moreover, when back to 2005
-there was an attempt to add MC/S in Linux, it was rejected. See for more details:
+there was an attempt to add MC/S in Linux, it was rejected. See for more details
http://article.gmane.org/gmane.linux.scsi/15769
and http://article.gmane.org/gmane.linux.scsi/16301.
But for sake of completeness, there are marginal cases, where MPIO
-can't be used or will not provide any benefit, but MC/S can provide
-benefits:
+can't be used or will not provide any benefit, but MC/S can be successful:
- When strict commands order is required.
@@ -233,13 +232,13 @@ and backup applications one or both can be true. But on practice:
limitation of legacy tape drives, which support only implicit
address commands, not of MPIO. Modern tape drives and backup
applications can use explicit address commands, which you can
- abort and then retry, hence compatible with MPIO.
+ abort and then retry, hence they are compatible with MPIO.
-If in future SCSI standards have possibility to group several I_T nexuses
+
If in future SCSI standards gain possibility to group several I_T nexuses
with possibilities to reassign commands between them and preserve commands
-order among them, the above the only advantages of MC/S over MPIO will be
+order among them, the above minor advantages of MC/S over MPIO will be
removed and, hence, all investments in it will be voided.