mirrors/scst
1
0
Fork 0
mirror of https://github.com/SCST-project/scst.git synced 2026-05-20 04:01:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

Web updates. Particularly, scst_pg has changes suggested by Sam Haxor <generationgnu@yahoo.com>

Browse Source 
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@858 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Vladislav Bolkhovitin
2009-05-18 18:08:04 +00:00
parent f3d5d989ca
commit 1e1476089d
5 changed files with 3397 additions and 3247 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
www/comparison.html
View File

@@ -117,7 +117,7 @@ transfer values (parallel SCSI, SAS) </th> <td> + </td> <td> - </td> <td> -
<sup><A HREF="#9">9</A></sup></th> <td> + </td> <td> - </td> <td> - </td> <td> - </td>
</tr>
<tr>
<th align="left"> Advanced LUNs access control
<th align="left"> Advanced devices access control
<sup><A HREF="#10">10</A></sup></th> <td> + </td> <td> - </td> <td> - </td> <td> - </td>
</tr>
<tr>
@@ -154,11 +154,11 @@ SCSI requirements <sup><A HREF="#12">12</A></sup></th> <td> Safe </td> <td> S
<th align="left"> Support for SCSI task attributes, including
ORDERED commands</th> <td> + </td> <td> + </td> <td> -, <br/> data
corruption possible
<sup><A HREF="#20">
20</A></sup></td> <td> -, <br/>data
<sup><A HREF="#21">
21</A></sup></td> <td> -, <br/>data
corruption possible
<sup><A HREF="#20">
20</A></sup> </td>
<sup><A HREF="#21">
21</A></sup> </td>
</tr>
<tr>
<th align="left"> Persistent Reservations <br/>
@@ -172,7 +172,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="#14">14</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>
@@ -225,14 +225,15 @@ ORDERED commands</th> <td> + </td> <td> + </td> <td> -, <br/> data
<th align="left"> User space FILEIO </th> <td> + </td> <td> + </td> <td> - </td> <td> - </td>
</tr>
<tr>
<th align="left"> SCSI pass-through </th> <td> + </td> <td> - </td> <td> - </td> <td> Single initiator only, not enforced
<sup><A HREF="#15">15</A></sup></td>
<th align="left"> SCSI pass-through
<sup><A HREF="#16">16</A></sup></th> <td> + </td> <td> - </td> <td> - </td> <td> Single initiator only, not enforced
<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="#16">16</A>
<A HREF="#18">18</A>
</sup></td> <td> - <sup>
<A HREF="#8">8</A>
</sup> </td> <td> BLOCKIO </td> <td> BLOCKIO, pass-
@@ -275,7 +276,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="#17">17</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>
@@ -302,13 +303,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="#18">18</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="#19">19</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="#14">14</A></sup></td>
<sup><A HREF="#15">15</A></sup></td>
</tr>
</table>
@@ -349,7 +350,7 @@ reinstatement <sup><A HREF="#18">18</A></sup></th> <td> Safe </td> <td> Not s
locally on the target host. For instance, you can mount your ISO image from emulated by the target
CDROM device locally on the target host.</p>
<p><A NAME="10"></A> 10. "Advanced devices LUNs control" means that different initiators can see different sets
<p><A NAME="10"></A> 10. "Advanced devices access control" means that different initiators can see different sets
of devices from the same target. This feature is required for hardware targets, which don't have ability
to create virtual targets.</p>
@@ -371,33 +372,37 @@ reinstatement <sup><A HREF="#18">18</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="14"></A> 14. The IETF SCSI-MIB (RFC 4455) is not supported by LIO, only proprietary MIBs SBE-SCSI-MIB, SBE-ISCSI-MIB and SBE-IPS-AUTH-MIB are supported.</p>
<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="15"></A> 15. LIO doesn't emulate all the necessary SCSI host functionality to allow to share a SCSI device
in pass-through mode to several initiators. It can only pass SCSI commands from initiator to
the SCSI device and response back. This is safe only with a single initiator. This limitation
isn't enforced anyhow, so you can accidentally corrupt your data. You can find more technical information about that in
<p><A NAME="15"></A> 15. The IETF SCSI-MIB (RFC 4455) is not supported by LIO, only proprietary MIBs SBE-SCSI-MIB, SBE-ISCSI-MIB and SBE-IPS-AUTH-MIB are supported.</p>
<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="17"></A> 17. LIO doesn't emulate all the necessary SCSI host functionality to allow to share SCSI devices
in pass-through mode to several initiators. It 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 LIO doesn't issue no warning about it, so you can quietly corrupt your data.
You can find more technical information about that in
<a href="http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg06911.html">
http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg06911.html</a></p>
<p><A NAME="16"></A> 16. You can find 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 proposal how to implement zero-copy FILEIO in SCST on the <a href="contributing.html#ZC_READ">
Contributing</a> page.</p>
<p><A NAME="17"></A> 17. Doesn't need any kernel patch, except in case, when used with user space backend.</p>
<p><A NAME="19"></A> 19. Doesn't need any kernel patch, except in case, when used with user space backend.</p>
<p><A NAME="18"></A> 18. 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="19"></A> 19. "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.</p>
<p><A NAME="20"></A> 20. 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 curruption to any application relying on commands order provided by ORDERED attribute.</p>
<!-- <p><small><strong>P.S.</strong> You can find a brief background history of this comparison page <a href="comparison_history.html">here</a>.</small></p> -->

27
www/index.html
View File

@@ -43,7 +43,7 @@
<strong>automatic backup</strong>, etc. Another class of such devices
are <strong>Virtual Tape Libraries</strong> (VTL)
as well as other disk-based backup solutions. SCST created devices not
limited by IP network interface only. They can use any link supporting
limited by IP networking only. They can use any link which supports
SCSI-style data exchange, including <strong>Fibre Channel</strong>,
<strong>iSCSI</strong>, <strong>SAS</strong>,
<strong>InfiniBand</strong> and <strong>parallel (Wide) SCSI</strong>. It might
@@ -55,10 +55,10 @@
<h1>Features of SCST Core</h1>
<ul>
<li><span>Simple, easy to use interface with target drivers.
<li><span>SCST core has simple, easy to use interface with target drivers.
SCST core performs all required pre- and post- processing of incoming requests as well as
necessary error recovery.</span></li>
<li><span>Undertakes most problems, related to execution contexts, thus practically eliminating one of the most
<li><span>SCST core undertakes most problems, related to execution contexts, thus practically eliminating one of the most
complicated problem in the kernel drivers development. For example, target drivers for QLogic
22xx/23xx cards and for InfiniBand SRP are only about 2300 lines of code long.</span></li>
<li><span>Very low overhead, fine-grained locks and simplest commands processing path allow to reach
@@ -68,14 +68,14 @@
<li><span>Device handlers, i.e. plugins, architecture allows various I/O
modes in backstorage handling. For example, pass-through device handlers allows to use real
SCSI hardware and vdisk device handler allows to use files as virtual disks.</span></li>
<li><span>Provides advanced per-initiator devices visibility management (LUN masking) allows different
<li><span>Advanced per-initiator devices visibility management (LUN masking) allows different
initiators to see different set of devices with different access permissions. For instance,
initiator A could see exported from target T devices X and Y read-writable, and initiator B from
the same target T could see devices Y read-only and Z read-writable.
This feature is required for hardware targets, which don't have ability to create
virtual targets (SAS adapters, for instance).</span></li>
<li><span>Emulates necessary functionality of SCSI host adapter, because from remote initiators' point of view
SCST acts as a SCSI host with its own devices. This is especially important in pass-through mode with
<li><span>SCST core emulates necessary functionality of SCSI host adapter, because from remote initiators' point of view
a SCSI target acts as a SCSI host with its own devices. This is especially important in pass-through mode with
one to many relationship, i.e. when multiple initiators can connect to the exported pass-through
devices. You can find more deep elaboration why it is needed in <a href=http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg06911.html>this</a>
message in thread "Question for pass-through target design" in linux-scsi mailing list. Some of the emulated functions are the following:
@@ -98,25 +98,26 @@
</ul>
</span></li>
<li><span>Multithreaded design and complete SMP support, so, if necessary, all your CPU cores will participate in the commands
<li><span>SCST core has multithreaded design and complete SMP support, so, if necessary, all your CPU cores will participate in the commands
processing.</span></li>
<li><span>Well documented.</span></li>
</ul>
<p>Interoperability between SCST core and local SCSI initiators (i.e. sd, st, etc.) is the additional issue that SCST is going to
<p>Interoperability between remote and local SCSI initiators (i.e. sd, st, etc.) is the additional issue that SCST is going to
address (it is not implemented yet). It is necessary, because local SCSI initiators can change the state of the
device, for example RESERVE the device, or some of its parameters and that could be done behind SCST, which could
device, for example RESERVE the device, or some of its parameters and that could be done behind SCST, i.e. remote initiators
will not know about it, which could
lead to various problems, including data corruption. Thus, RESERVE/RELEASE commands, locally generated
UNIT ATTENTIONs, etc. should be intercepted and processed as if local SCSI initiators act as remote SCSI
initiators connected to SCST.</p>
UNIT ATTENTIONs, etc. should be intercepted and passed through SCST core.</p>
<h1>SCST core supports the following I/O modes</h1>
<ul>
<li><span><strong>Pass-through mode</strong> with one to many relationship, i.e. when multiple initiators can
connect to the exported pass-through devices, for virtually all SCSI devices types: <strong>disks (type 0),
tapes (type 1), processors (type 3), CDROMs (type 5), MO disks (type 7), medium changers (type 8) and RAID
controllers (type 0xC)</strong>.</span></li>
controllers (type 0xC)</strong>. In this mode you can, for instance, share your parallel SCSI tape or SATA
DVD-RW device to your iSCSI network.</span></li>
<li><span><strong>FILEIO mode</strong>, which allows to use files on file systems or block devices as virtual
remotely available SCSI disks or CDROMs with benefits of the <strong>Linux page cache</strong>.</span></li>
remotely available SCSI disks or CDROMs with benefits of the Linux <strong>cache</strong>.</span></li>
<li><span><strong>BLOCKIO mode</strong>, which performs direct block IO with a block device, bypassing
page-cache for all operations. This mode works well with high-end storage HBAs and for applications that
either do not need caching between application and disk or need the large block throughput.</span></li>

15
www/scst_pg.html
View File

@@ -89,9 +89,20 @@
<p><strong>SCSI initiator device</strong><br><br>
A SCSI device that originates service and task management requests to be processed by a SCSI target device and
receives device service and task management responses from SCSI target devices.</p>
<p>Think of the 'SCSI LLDD' as a BE (Back End) driver.</p>
<p><strong>SCSI target device</strong><br><br>
A SCSI device that receives device service and task management requests for processing and sends device service
and task management responses to SCSI initiator devices or drivers.</p>
<p>Think of the 'Target Driver' as an FE (Front End) driver.</p>
<p>The FE driver interfaces to the initiators (via the
storage-fabric-cloud) and also to the upper edge of the SCST. Whereas
the BE driver interfaces to the targets, i.e. disk-enclosures/JBODs/tapes etc.
and also to the bottom edge of the SCST.</p>
<p><strong>SCST session</strong><br><br>
SCST session is the object that describes relationship between a remote initiator and SCST via a target driver.
All the commands from the remote initiator is passed to SCST in the session. For example, for connection oriented
@@ -348,10 +359,10 @@
function.<br>Then:<ul>
<li><span>If the command required no data transfer, it will be passed to SCSI mid-level directly or
via device handler's <strong>exec()</strong> call.</span></li>
<li><span>If the command is <strong>READ</strong> command (data to the target), necessary space will be
<li><span>If the command is a <strong>READ</strong> command (data to the remote/local initiator), necessary space will be
allocated and then the command will be passed to SCSI mid-level directly or via device handler's
<strong>exec()</strong> call.</span></li>
<li><span>If the command is <strong>WRITE</strong> command (data from the target), necessary space will be
<li><span>If the command is a <strong>WRITE</strong> command (data from the remote/local initiator), necessary space will be
allocated, then the target's <strong>rdy_to_xfer()</strong> function will be called, telling the target that
the space is ready and it can start data transferring. When all the data are read from the target, it will call
<strong>scst_rx_data()</strong>, and the command will be passed to SCSI mid-level directly or via device

6480
www/scst_pg.pdf
View File

File diff suppressed because it is too large Load Diff

63
www/target_iscsi.html
View File

@@ -59,57 +59,52 @@
which doesn't touch the core code, could be merged, it is very unlikely that they will be merged in the main
<strong>IET</strong> trunk.</p>
<p><strong>ISCSI-SCST</strong> has the following major advantages over <strong>IET</strong>:
<p><strong>ISCSI-SCST</strong> has the following major advantages over <strong>IET</strong>. They are summarized on the
<a href="comparison.html">Comparison</a> page.
<ul>
<li><span>It uses full power of <strong>SCST core</strong> without loosing any existing IET feature.
Comparing to IET it has the following additional features:
<li><span>ISCSI-SCST uses full power of <strong>SCST core</strong>, hence has the following additional features:
<ul>
<li><span><strong>Pass-through mode with one to many relationship</strong>, i.e. when multiple initiators can connect to the
exported pass-through devices. For instance, you can safely export your parallel
<li><span><strong>Pass-through mode with one to many relationship</strong>, i.e. when multiple initiators can connect to
exported pass-through devices. For instance, in this mode you can safely export your parallel
<strong>SCSI tape</strong> or <strong>tape library</strong> on
your iSCSI net and multiple initiators can share it without risk of data loss because of the
shared usage. Existing "rawio" patch for IET supports only non-enforced 1:1
shared usage. Existing outdated "rawio" patch for IET supports only non-enforced 1:1
relationship, so it is unsafe to use it in multiple initiators environments.</span></li>
<li><span><strong>More advances devices visibility management</strong>, when different initiators can see different set of
<li><span><strong>More advanced devices visibility management</strong>, when different initiators can see different set of
devices with different access permissions from the same target.</span></li>
<li><span><strong>O_DIRECT</strong>, i.e. "<strong>BLOCKIO</strong> on files", mode, which has all advantages
of <strong>BLOCKIO</strong>, but also supports files on file systems. Sometimes, in the appropriate cases,
<li><span><strong>O_DIRECT</strong>, i.e. <strong>"BLOCKIO on files"</strong>, mode, which has all advantages
of BLOCKIO, but also supports files on file systems. Sometimes, in the appropriate cases,
this mode can make performance difference in 100% or even more.</span></li>
<li><span>With <strong>4KB blocks</strong> you can forget about abysmal write performance caused by misaligned partitions.
All modern OS'es, including Windows starting from Windows 2000, work perfectly with 4KB block
devices without any additional storage or handling overhead.</span></li>
<li><span><strong>Virtual CD/DVD-ROMs</strong> without necessity for manual patching.</span></li>
<li><span><strong>4KB blocks</strong> eliminate abysmal write performance caused by misaligned partitions.
</span></li>
<li><span><strong>Virtual CD/DVD-ROMs</strong>.</span></li>
<li><span>Ability to create target devices emulators in the <strong>user space</strong>.</span></li>
<li><span>Ability to create <strong>multi-transport SCSI targets</strong>, which can export (possibly, the same)
devices over multiple transports.</span></li>
</ul>
</span></li>
<li><span>It has many code improvements and cleanups, including <strong>stability and iSCSI RFC violations fixes</strong>.
Many IET users use it for ages without problems, so they consider it free from any real problem. But,
in fact, unfortunately, it isn't so.
IET works well only on "fast" paths and regularly used code branches. In many other less used
cases IET has various problems, from simply ignoring error processing, as it is with memory
<li><span>ISCSI-SCST has many code improvements and cleanups, including <strong>stability</strong>
and <strong>iSCSI RFC violations fixes</strong>.
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.
ChangeLog file lists most noticeable fixes, but there were a lot of many other smaller ones.</span></li>
thread on a VMware forum about in which <strong>Russian roulette</strong> IET users play using it with VMware.</span></li>
<li><span>Due to reworked I/O architecture and SCST backend iSCSI-SCST has
better performance in many cases. In future with upcoming improvements in SCST core, like <strong>zero-copy
with Linux cache FILEIO</strong>, the performance difference is going to be even bigger. For instance, in
tests from a single initiator over a single connection on 1GbE hardware using vdisk handler
iSCSI-SCST with default settings in many cases outperforms tuned for best
performance IET on <strong>more than 100%</strong>. See
<a href="http://lkml.org/lkml/2009/3/30/283">those measurements</a>, for example. The difference is especially
noticeably with real storage, not NULLIO or RAM disks. This is because
iSCSI-SCST has less commands processing overhead per command, hence has smaller processing
latency and puts less load on CPU.
<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>.
</ul></p>
<p>Also, in contrast to IET, iSCSI-SCST is open for any new development, modifications and
improvements, so people who want to fix or implement something new will not have to keep and maintain separate
patches as it is currently necessary with IET.</p>
<p>If you are an IET user before installation carefully read README files of both iSCSI-SCST and
the SCST core. Especially pay attention that now the LUN information for iSCSI-SCST is configured not using
iscsi-scstd.conf file in /etc, but using corresponding SCST facilities. This is because now the responsibilities