mirrors/scst
1
0
Fork 0
mirror of https://github.com/SCST-project/scst.git synced 2026-05-14 09:11:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Docs and web updates

Browse Source 
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1187 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Vladislav Bolkhovitin
2009-10-08 13:44:55 +00:00
parent 38298ed9b3
commit b40aa9fa94
5 changed files with 49 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
qla2x00t/qla2x00-target/README
View File

@@ -17,6 +17,14 @@ Linux kernel 2.6.26 and higher. Sorry, kernels below 2.6.26 are not
supported, because it's too hard to backport used initiator driver to
older kernels.
NPIV is particulary supported by this driver. You can create virtual
targets using standard Linux interface by echoing wwpn:wwnn into
/sys/class/fc_host/hostX/vport_create and work with them, but SCST core
will not see those virtual targets and, hence, provide the
target-oriented access control for them. However, the initiator-oriented
access control will still work very well. Note, you need NPIV-supporting
firmware as well as NPIV-supporting switches to use NPIV.
The original initiator driver was taken from the kernel 2.6.26.
See also "ToDo" file for list of known issues and unimplemented
@@ -82,6 +90,8 @@ You can find some installation and configuration HOWTOs in
http://scst.sourceforge.net/qla2x00t-howto.html and
https://forums.openfiler.com/viewtopic.php?id=3422.
It is recommended to use firmware version 5.x.x or higher.
Explicit conformation
---------------------

5
qla2x00t/qla2x00-target/ToDo
View File

@@ -1,7 +1,8 @@
Known issues and unimplemented features
---------------------------------------
- NPIV support
- Complete NPIV support. Particularly, SCST core should see all the virtual
targets and provide separate target-oriented access control for them.
- If a Linux initiator asks for devices using INQUIRY command too soon
before the controller on the 23xx target is fully initialized in the
@@ -21,5 +22,5 @@ Known issues and unimplemented features
and then read it with bs <X the tape skips all blocks with size X
until the next correct block or filemark found, instead of returning
ILI with negative counter. Looks like the initiator retries the
command quetly. 22xx works correctly. With the latest firmware that
command quietly. 22xx works correctly. With the latest firmware that
might be fixed.

57
www/comparison.html
View File

@@ -44,7 +44,7 @@
<div id="main">
<h1>Features comparison between Linux SCSI targets</h1>
<p><small>As on August 2009</small></p>
<p><small>As on October 2009</small></p>
<table bgcolor="#F0F0F0" border="1" cols="5" cellspacing="1" cellpadding="7" style="text-align:center" width="620">
@@ -147,22 +147,21 @@ any target reconfiguration in a PnP-like fashion) </th> <td> + </td> <td> - <
<small> (Windows 2003 clustering) </small></th> <td> + </td> <td> + </td> <td> + </td> <td> + </td>
</tr>
<th align="left"> Safe RESERVE/RELEASE implementation according to
SCSI requirements <sup><A HREF="#12">12</A></sup></th> <td> Safe </td> <td> Safe </td> <td> Not safe
<sup><A HREF="#13">
13</A></sup> </td> <td> Not safe </td>
SCSI requirements <sup><A HREF="#12">12</A></sup></th> <td> Safe </td> <td> Safe </td> <td> Safe from
v1.4.18</td> <td> Not safe </td>
</tr>
<th align="left"> Safe implementation of Task Management commands
<sup><A HREF="#14">14</A></sup></th> <td> Safe </td> <td> Not safe </td> <td> Not safe </td> <td> Not safe </td>
<sup><A HREF="#13">13</A></sup></th> <td> Safe </td> <td> Not safe </td> <td> Not safe </td> <td> Not safe </td>
</tr>
<tr>
<th align="left"> Support for SCSI task attributes, including
ORDERED commands</th> <td> + </td> <td> + </td> <td> -, <br/> data
corruption possible
<sup><A HREF="#15">
15</A></sup></td> <td> -, <br/>data
<sup><A HREF="#14">
14</A></sup></td> <td> -, <br/>data
corruption possible
<sup><A HREF="#15">
15</A></sup> </td>
<sup><A HREF="#14">
14</A></sup> </td>
</tr>
<tr>
<th align="left"> Persistent Reservations <br/>
@@ -180,7 +179,7 @@ ORDERED commands</th> <td> + </td> <td> + </td> <td> -, <br/> data
</tr>
<tr>
<th align="left"> SCSI MIBs </th> <td> - </td> <td> - </td> <td> - </td> <td> +-
<sup><A HREF="#16">16</A></sup></td>
<sup><A HREF="#15">15</A></sup></td>
</tr>
<tr>
<th align="left"> Cluster Storage Integration </th> <td> - </td> <td> - </td> <td> - </td> <td> VHACS </td>
@@ -237,18 +236,18 @@ ORDERED commands</th> <td> + </td> <td> + </td> <td> -, <br/> data
</tr>
<tr>
<th align="left"> SCSI pass-through
<sup><A HREF="#17">17</A></sup></th> <td> + </td> <td> Disks only, single
<sup><A HREF="#16">16</A></sup></th> <td> + </td> <td> Disks only, single
initiator only, not
enforced <sup>
<A HREF="#18">18</A>
<A HREF="#17">17</A>
</sup> </td> <td> - </td> <td> Single initiator only, not enforced
<sup><A HREF="#18">18</A></sup></td>
<sup><A HREF="#17">17</A></sup></td>
</tr>
<tr>
<th align="left"> Zero-copy data read/write to/from backstorage</th> <td>BLOCKIO, user space
FILEIO in O_DIRECT mode,
pass-through <sup>
<A HREF="#19">19</A>
<A HREF="#18">18</A>
</sup></td> <td> - <sup>
<A HREF="#8">8</A>
</sup> </td> <td> BLOCKIO </td> <td> BLOCKIO, pass-
@@ -291,7 +290,7 @@ devices</th> <td> - </td> <td>Experimental</td> <td> - </td> <td> - </t
</tr>
<tr>
<th align="left"> Zero-copy data send/receive</th> <td> Send only<sup>
<A HREF="#20">20</A>
<A HREF="#19">19</A>
</sup> </td> <td> None <sup>
<A HREF="#8">8</A>
</sup> </td> <td> Send only</td> <td> Send only </td>
@@ -318,13 +317,13 @@ devices</th> <td> - </td> <td>Experimental</td> <td> - </td> <td> - </t
(AEN) </th> <td> + </td> <td> - </td> <td> - </td> <td> - </td>
</tr>
<th align="left"> Safe implementation of connections and sessions
reinstatement <sup><A HREF="#21">21</A></sup></th> <td> Safe </td> <td> Not safe </td> <td> Not safe </td> <td> Not safe </td>
reinstatement <sup><A HREF="#20">20</A></sup></th> <td> Safe </td> <td> Not safe </td> <td> Not safe </td> <td> Not safe </td>
</tr>
<th align="left"> Safe restart <sup><A HREF="#22">22</A></sup></th> <td> Safe </td> <td> ? </td> <td> Not safe </td> <td> ?</td>
<th align="left"> Safe restart <sup><A HREF="#21">21</A></sup></th> <td> Safe </td> <td> ? </td> <td> Not safe </td> <td> ?</td>
</tr>
<tr>
<th align="left"> iSCSI MIBs </th> <td> - </td> <td> - </td> <td> - </td> <td> +-
<sup><A HREF="#16">16</A></sup></td>
<sup><A HREF="#15">15</A></sup></td>
</tr>
</table>
@@ -377,11 +376,7 @@ reinstatement <sup><A HREF="#21">21</A></sup></th> <td> Safe </td> <td> Not s
community forum by someone working for VMware. But, sure, it can affect not only VMware, but also any other cluster
implementation, relying on this functionality.</p>
<p><A NAME="13"></A> 13. The problem in IET
<a href="http://sourceforge.net/mailarchive/message.php?msg_name=1239130617.11478.1282.camel%40blackadder">
was confirmed</a> in IET mailing list.</p>
<p><A NAME="14"></A> 14. After a task management command completed and before the corresponding response was sent to the initiator, who sent that task management
<p><A NAME="13"></A> 13. After a task management command completed and before the corresponding response was sent to the initiator, who sent that task management
command, all the affected SCSI commands must get into a state, where they can't affect following after
the tasks management response commands from this initiator. This is the safe implementation.
The unsafe implementation only marks all the affected
@@ -391,35 +386,35 @@ reinstatement <sup><A HREF="#21">21</A></sup></th> <td> Safe </td> <td> Not s
SCSI command, which initiator will send after it received the task management response thinking
that all the aborted commands actually fully aborted. This could lead to a data corruption.</p>
<p><A NAME="15"></A> 15. Both IET and LIO report in INQUIRY command response support for full task management model. But they process ORDERED
<p><A NAME="14"></A> 14. Both IET and LIO report in INQUIRY command response support for full task management model. But they process ORDERED
commands the same way as SIMPLE commands, i.e. allow free reorder of them before they get executed. That violates SCSI standard
and can lead to a data corruption to any application relying on commands order provided by ORDERED attribute.</p>
<p><A NAME="16"></A> 16. LIO exports the information needed for an RFC 4455 implementation, but requires additional RFC 4455 implementing module.
<p><A NAME="15"></A> 15. LIO exports the information needed for an RFC 4455 implementation, but requires additional RFC 4455 implementing module.
At the moment, there is no open source implementation of such module.</p>
<p><A NAME="17"></A> 17. SCSI pass-through mode allows to export your local SCSI-capable device. For instance with it you can share your parallel
<p><A NAME="16"></A> 16. SCSI pass-through mode allows to export your local SCSI-capable device. For instance with it you can share your parallel
SCSI tape or SATA DVD-RW device to your iSCSI network.</p>
<p><A NAME="18"></A> 18. STGT and LIO don't emulate all the necessary SCSI host functionality to allow to share SCSI devices
<p><A NAME="17"></A> 17. STGT and LIO don't emulate all the necessary SCSI host functionality to allow to share SCSI devices
in pass-through mode to several initiators. They can only pass SCSI commands from initiators to
SCSI devices and responses back. This is safe only with a single initiator. This limitation
isn't enforced anyhow and both STGT and LIO don't issue any warning about it, so an user will not be notified about this
limitation and can quietly corrupt his/her data. You can find more technical information about it
<a href="http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg06911.html">here</a>.</p>
<p><A NAME="19"></A> 19. You can find a proposal how to implement zero-copy FILEIO in SCST on the <a href="contributing.html#ZC_READ">
<p><A NAME="18"></A> 18. You can find a proposal how to implement zero-copy FILEIO in SCST on the <a href="contributing.html#ZC_READ">
Contributing</a> page.</p>
<p><A NAME="20"></A> 20. Doesn't need any kernel patch, except in the case, when used with user space backend.</p>
<p><A NAME="19"></A> 19. Doesn't need any kernel patch, except in the case, when used with user space backend.</p>
<p><A NAME="21"></A> 21. Connections and sessions reinstatement is, basically, a kind of Task Management command, because it implies commands aborting.
<p><A NAME="20"></A> 20. Connections and sessions reinstatement is, basically, a kind of Task Management command, because it implies commands aborting.
For instance, open-iscsi uses it as a less intrusive substistute for target reset in eh_target_reset_handler() callback. So, similarly
to the safe task management above, a safe implementation of connections and sessions reinstatement
must not accept SCSI commands from new connection/session until all the SCSI commands in
being reinstated connection/session get into a state, where they can't affect new commands.</p>
<p><A NAME="22"></A> 22. "Safe restart" means that after the iSCSI target restart, all the connected initiators will seamlessly restore all existing before
<p><A NAME="21"></A> 21. "Safe restart" means that after the iSCSI target restart, all the connected initiators will seamlessly restore all existing before
the restart connections. "Not safe" means that, most likely, the connected initiators will fail to restore
existing connections with some errors. However, your iSCSI initiator also should be able to handle the safe restart. For instance,
old (pre-CentOS/RHEL 5) open-iscsi has problems in this area. But the latest versions do it pretty well.</p>

13
www/target_iscsi.html
View File

@@ -93,18 +93,17 @@
</span></li>
<li><span>ISCSI-SCST has many code improvements and cleanups, including <strong>stability</strong>
and <strong>iSCSI RFC violations fixes</strong>.
<li><span>ISCSI-SCST has many code improvements and cleanups, including stability
and iSCSI RFC violations fixes.
IET works well on "fast" paths and regularly used code branches, but in many corner
cases it has various problems, from simply ignoring error processing, as it is for memory
allocations, and crashing itself with BUG() macro, as it is for malformed packets from initiators, to possible data
corruption. See, for instance, <a href="http://communities.vmware.com/thread/53797?tstart=0&start=15">this</a>
thread on a VMware forum about in which <strong>Russian roulette</strong> IET users play using it with VMware.</span></li>
corruptions, because of, for instance, unsafe task management or sessions reinstatement implementations.</span></li>
<li><span>Due to reworked I/O architecture and SCST backend iSCSI-SCST has much
better performance in many cases and has potential for future improvements, like <strong>zero-copy
with Linux cache FILEIO</strong>. In many tests iSCSI-SCST outperforms tuned for best
performance IET on <strong>more than 100%</strong>.
better performance in many cases and has potential for future improvements, like zero-copy
with Linux cache FILEIO. In many tests iSCSI-SCST outperforms tuned for best
performance IET on more than 100%.
</ul></p>
<p>If you are an IET user before installation carefully read README files of both iSCSI-SCST and

7
www/target_qla_isp.html
View File

@@ -63,9 +63,10 @@
Stanislaw Gruszka for Open-E Inc.</p>
<p>This driver operates on the same hardware as the qla2x00t target driver, but, comparing to version 1.0.1.1
of it, has two notable advantages: support of 24xx (4Gbps) and 25xx (8Gbps) series of QLogic adapters as well
as NPIV support. From other side, qla2x00t is simpler, smaller and much better tested on 22xx and 23xx, hence perform more
reliable and, thus, is recommended for these adapters.</p>
of it, has a notable advantage: support of 24xx (4Gbps) and 25xx (8Gbps) series of QLogic adapters.
From other side, qla2x00t is simpler, smaller and much better tested on 22xx and 23xx, hence perform more
reliable and, thus, is recommended for these adapters. (Support of 24xx (4Gbps) and 25xx (8Gbps)
series of QLogic adapters was added in version 2.0.0 of qla2x00t.)</p>
<p>The latest release is 1.0.1. It does not support 25xx chipsets yet and can be compiled with Linux
kernel versions between 2.6.16 and 2.6.27. You can find support for 25xx chipsets and the latter kernels