diff --git a/www/index.html b/www/index.html
new file mode 100644
index 000000000..3adfdfc2f
--- /dev/null
+++ b/www/index.html
@@ -0,0 +1,15 @@
+
+
+
+ SCST: Generic SCSI Target Middle Level for Linux
+
+
+
+
+
+
diff --git a/www/main.html b/www/main.html
new file mode 100644
index 000000000..df82950f2
--- /dev/null
+++ b/www/main.html
@@ -0,0 +1,199 @@
+
+
+
+
+ SCST: Generic SCSI Target Middle Level for Linux
+
+
+
+Generic SCSI Target Middle Level for Linux
+
+The SCSI target mid-level subsystem for
+Linux (SCST) is a subsystem of the Linux kernel that provides a
+standard framework for SCSI target drivers development. It is designed
+to
+provide unified, consistent interface between SCSI target drivers and
+Linux kernel and simplify target drivers development as much as
+possible. A system with a SCSI target device is able to share its local
+or virtual devices with other systems on a network with SCSI protocol
+support, e.g. SCSI bus, SAS, Fibre Channel or iSCSI. This is
+commonly used for data storage virtualization.
+
+SCST has the following features:
+
+
+
+
+
+
+
+ - Simple, easy to use interface with target drivers. Particularly,
+SCST performs all required pre- and post- processing of incoming
+requests and all necessary error recovery.
+ - Undertakes most problems, related to execution contexts, thus
+practically eliminating one of the most complicated problem in the
+kernel drivers development. For example, a target driver for QLogic
+2200/2300 cards, which has all necessary features, is only ~2000 lines
+of code long.
+ - Very low overhead, fine-grained locks and simplest commands
+processing path, which allow to reach maximum possible performance and
+scalability. Particularly, incoming
+requests can be processed in the caller's context or in
+one of the internal SCST's tasklets, therefore no extra context
+switches
+required.
+
+ - Device handlers, i.e. plugins, architecture provides extra
+flexibility by allowing 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.
+ - Provides advanced per-initiator device visibility management (LUN
+masking),
+which allows different initiators to see different set of devices
+with different access permissions. For instance, initiator A could see
+exported from
+target T devices Da and Db read-writable, and initiator B from the same
+target T could see devices Db read-only and Dc read-writable.
+
+ - 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 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 this
+message in linux-scsi mailing list. Some of the emulated functions are
+the following:
+
+ - Generation of necessary UNIT ATTENTIONs, their storage and
+delivery to all connected remote initiators.
+ - RESERVE/RELEASE functionality.
+ - CA/ACA conditions (not implemented yet).
+ - All types of RESETs and other task management functions.
+ - REPORT LUNS command as well as SCSI address space management
+in order to have consistent address space on all remote initiators,
+since local SCSI devices could not know about each other to report
+via REPORT LUNS command. Additionally, SCST responds with error on
+all commands to non-existing devices and provides access control, so
+different remote initiators could see
+different set of devices.
+ - Other necessary functionality (task attributes, etc.) as
+specified in SAM-2, SPC-2, SAM-3, SPC-3 and other SCSI standards.
+
+
+ - Multithreaded design and complete SMP support, so all your
+processors will participate in the commands processing.
+
+ - Well documented.
+
+
+
+
+Interoperability between SCST 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 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.
+
+Interface between SCST and target
+drivers is based on work, done by University
+of New Hampshire Interoperability Labs (UNH IOL) for the UNH-iSCSI
+project, which was developed on SourceForge.net.
+
+SCST supports the following I/O modes:
+
+
+ - Pass-through mode with one to many relationship, i.e. when
+multiple initiators can connect to the exported pass-through devices,
+for virtually all SCSI devices types: 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)
+ - FILEIO mode, which allows to use files on file
+systems or block devices as virtual remotely available SCSI disks or
+CDROMs with benefits of the Linux page cache
+
+ - BLOCKIO mode, which performs direct block IO with a block device,
+bypassing page-cache for all operations. This mode works ideally with
+high-end storage HBAs and for applications that either do not need
+caching between application and disk or need the large block throughput.
+ - User space mode using scst_user device handler, which allows to
+implement in the user space virtual SCSI devices in the SCST environment
+
+ - "Performance" device handlers, which provide in pseudo
+pass-through mode a way for direct
+performance measurements without overhead of actual data transferring
+from/to underlying SCSI device
+
+
+The latest stable version is 0.9.5.
+Requires Linux kernel 2.6.14 or higher.
+Tested mostly on i386 and x86_64,
+but should also
+work on any other
+supported by Linux platform. More detail information you could find in
+the SCST README file.
+
+Starting from version 0.9.4 2.4 Linux
+kernels are not supported anymore. The latest
+stable
+version of SCST for 2.4 kernels is 0.9.3.1-24.
+If you have any questions you can ask
+them via scst-devel
+mailing list or forum.
+See main SCST page on SF.net for more info how to subscribe on
+scst-devel mailing list.
+
+Documentation: HTML,
+PDF, scst_user
+interface description
+Some nice SCST call graphs, created by Ming Zhang: init_scst, scst_cmd_thread, scst_mgmt_cmd_thread, scst_mgmt_thread
+The latest development version of SCST and target drivers is
+available directly from the
+project's SVN. The SCST release policy is to make stable releases once
+or
+twice a year, with the only exception if the current stable version
+contains a critical bug. But every commit in the SVN is carefully
+tested, so you can consider them as mini releases. Therefore on
+practice the development version
+in the SVN
+is usually more stable, than the "stable", i.e. released, one. You can
+access it using
+either web-based SVN
+repository viewer or using anonymous access:
+ svn co https://scst.svn.sourceforge.net/svnroot/scst
+
+More information about accessing SVN repository may be found here.
+
+History of the pre-SVN SCST development is available in SCST CVS
+repository, which is accessible using web-based CVS
+repository viewer or anonymous CVS access.
+
+Main SCST project
+page on SF.net
+Download
+released versions
+Change Log
+
+
+
+
diff --git a/www/menu.html b/www/menu.html
new file mode 100644
index 000000000..8873b83ba
--- /dev/null
+++ b/www/menu.html
@@ -0,0 +1,34 @@
+
+
+
+
+ SCST menu
+
+
+ 
+
+
+Home
+SCST admin
+iSCSI-SCST
+Target driver for
+QLogic
+2200/2300 cards
+Target driver for
+QLogic ISP
+chipsets
+SCSI RDMA Protocol (SRP)
+Target driver
+Target driver for LSI/MPT
+cards
+Old unsupported target
+drivers
+
SCST vs
+STGT
+
+
+
diff --git a/www/old-targets.html b/www/old-targets.html
new file mode 100644
index 000000000..297d1ca8d
--- /dev/null
+++ b/www/old-targets.html
@@ -0,0 +1,81 @@
+
+
+
+
+ SCST: Generic SCSI Target Middle Level for Linux
+
+
+
+Old target driver for QLogic 2200/2300 cards for 2.4 kernels
+
+Old target driver for QLogic
+2200/2300
+cards is capable to work on 2.4 kernels. It has all required features
+and
+looks to be quite stable. It is designed to work in conjunction with
+the initiator
+driver, which is intended to perform all the initialization and
+shutdown tasks. In the current release as a base for the initiator
+driver was taken Red Hat's driver from the stock 2.4.20 kernel. Then it
+was patched to enable the target mode and provide all
+necessary callbacks, and it's still able to work as initiator only.
+Mode, when a host acts as the initiator and the target simultaneously,
+is also supported. This driver is obsoleted in favor of
+2.6-based driver.
+
+The latest version is 0.9.3.4. Requires Linux kernel versions 2.4.20 or
+higher and SCST version 0.9.3-pre4 or higher. If you are lucky, it
+works also on 2.6 kernels, see README file
+for details. Tested on i386 only, but
+should work on any other supported by Linux platform.
+
+Currently it is not supported and listed here for historical reasons
+only.
+
+
+Download
+Change Log
+
+
+Target drivers for Adaptec 7xxx and QLogic QLA12xx
+cards
+Target drivers for Adaptec 7xxx and QLogic QLA12xx cards have
+been developed by Hu Gang and they available for download from http://bj.soulinfo.com/~hugang/scst/tgt/.
+These drivers are not completed, but looks to be a good starting point
+if you are going to use one of these cards.
+SCST team don't have the appropriate hardware, therefore have not
+tested and don't support these drivers. Send all questions to Hu Gang
+<hugang
+% soulinfo.com>. If some of these drivers don't compile for you, try
+again with SCST version 0.9.3-pre2.
+
+Download
+
+
+Patches for UNH-iSCSI Target 1.5.03 and 1.6.00 to work over
+SCST
+SCST is much more advanced, than the internal mid-level of UNH-iSCSI target
+driver.
+With SCST the iSCSI target benefits from all its features and gets
+ability to use all its advantages, like high performance and
+scalability, SMP support, required SCSI functionality emulation, etc.
+
+Since the interface between SCST and the target drivers is based on
+work, done by UNH IOL, it was relatively simple to update UNH-iSCSI
+target to work over SCST. Mostly it was "search and replace" job. The
+built-in scsi_target remains available as a compile-time option.
+
+Requires Linux kernel versions 2.4.20 or
+higher or 2.6.7 or higher and SCST version 0.9.2 or higher.
+
+Currently it is not supported and listed here for historical reasons
+only.
+
+Download
+
+
+
diff --git a/www/scst-stgt.html b/www/scst-stgt.html
new file mode 100644
index 000000000..5f9df907e
--- /dev/null
+++ b/www/scst-stgt.html
@@ -0,0 +1,50 @@
+
+
+
+
+ SCST: Generic SCSI Target Middle Level for Linux
+
+
+
+STGT is alternative, independent
+from SCST implementation of SCSI target framework for Linux. It has
+different architecture, where SCSI target state machine is placed in
+the user space, while in SCST all the processing done in the kernel.
+Such architecture was acknowledged as a "right" one by the Linux SCSI
+subsystem maintainers, so kernel's part of STGT quickly found its way
+to the kernel. But such architecture has two inherent problems, namely
+performance and complexity. See this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=472F7FA4.7040303%40wpkg.org&forum_name=scst-devel
+and this message: http://thread.gmane.org/gmane.linux.scsi/36417/focus=37273
+for more details.
+
+See also the following important discussions:
+
+Also you shouldn't be deceived by the fact
+that some (small) part of STGT was accepted in the kernel. It doesn't
+mean that STGT has the "kernel quality". In fact, STGT as a whole
+similarly to any other out-of-tree project lives on its own, hence has
+its own quality level, which isn't necessary better, than the quality
+level of SCST. Actually, from such important aspect of quality as
+simplicity, it might be quite contrary: e.g. SCST isn't required to
+support HIGHMEM (nowadays it isn't necessary, but required for all
+in-kernel components), which allowed to simplify memory management a
+lot.
+
+
+
diff --git a/www/scst_page.html b/www/scst_page.html
deleted file mode 100644
index 7b5940469..000000000
--- a/www/scst_page.html
+++ /dev/null
@@ -1,432 +0,0 @@
-
-
-
-
- SCST: Generic SCSI Target Middle Level for Linux
-
-
-
-
-Generic SCSI Target Middle Level for Linux
-
-The SCSI target mid-level subsystem for
-Linux (SCST) is a subsystem of the Linux kernel that provides a
-standard framework for SCSI target drivers development. It is designed
-to
-provide unified, consistent interface between SCSI target drivers and
-Linux kernel and simplify target drivers development as much as
-possible. A system with a SCSI target device is able to share its local
-or virtual devices with other systems on a network with SCSI protocol
-support, e.g. SCSI bus, Fibre Channel, TCP/IP with iSCSI. This is
-commonly used for data storage virtualization.
-
-SCST has the following features:
-
-
-
-
-
-
-
- - Simple, easy to use interface with target drivers. Particularly,
-SCST performs all required pre- and post- processing of incoming
-requests and all necessary error recovery.
- - Undertakes most problems, related to execution contexts, thus
-practically eliminating one of the most complicated problem in the
-kernel drivers development. For example, a target driver for QLogic
-2200/2300 cards, which has all necessary features, is only ~2000 lines
-of code long.
- - Very low overhead, fine-grained locks and simplest commands
-processing path, which allow to reach maximum possible performance and
-scalability. Particularly, incoming
-requests can be processed in the caller's context or in
-one of the internal SCST's tasklets, therefore no extra context
-switches
-required.
- - Provides advanced per-initiator device visibility management (LUN
-masking),
-which allows different initiators see different set of devices
-with different access permissions. For instance, initiator A could see
-exported from
-target T devices Da and Db read-writable, and initiator B from the same
-target T could see devices Db read-only and Dc read-writable.
-
- - 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 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 this
-message in linux-scsi mailing list. Some of the emulated functions are
-the following:
-
- - Generation of necessary UNIT ATTENTIONs, their storage and
-delivery to all connected remote initiators.
- - RESERVE/RELEASE functionality.
- - CA/ACA conditions (not implemented yet).
- - All types of RESETs and other task management functions.
- - REPORT LUNS command as well as SCSI address space management
-in order to have consistent address space on all remote initiators,
-since local SCSI devices could not know about each other to report
-via REPORT LUNS command. Additionally, SCST responds with error on
-all commands to non-existing devices and provides access control, so
-different remote initiators could see
-different set of devices.
- - Other necessary functionality (task attributes, etc.) as
-specified in SAM-2, SPC-2, SAM-3, SPC-3 and other SCSI standards.
-
-
- - Device handlers (i.e. plugins) architecture provides extra
-flexibility by allowing to make any additional
-requests processing, which is completely independent from target
-drivers and SCST core, like, for instance, device dependent exceptional
-conditions treatment, data caching or passing commands in the user
-space for device emulation. Example of such plugin is FILEIO device
-handler (see below) .
-
- - Complete SMP support.
-
- - Well documented.
-
-
-
-
-Interoperability between SCST 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 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.
-
-Interface between SCST and target
-drivers is based on work, done by University
-of New Hampshire Interoperability Labs (UNH IOL) for the UNH-iSCSI
-project, which is currently developed on SourceForge.net.
-
-SCST supports the following I/O modes:
-
-
- - Pass-through mode with one to many relationship, i.e. when
-multiple initiators can connect to the exported pass-through devices,
-for virtually all SCSI devices types: 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)
- - FILEIO mode, which allows to use files on file
-systems or block devices as virtual remotely available SCSI disks or
-CDROMs with benefits of the Linux page cache
-
- - BLOCKIO mode, which performs direct block IO with a block device,
-bypassing page-cache for all operations. This mode works ideally with
-high-end storage HBAs and for applications that either do not need
-caching between application and disk or need the large block throughput.
- - User space mode using scst_user device handler, which allows to
-implement in the user space virtual SCSI devices in the SCST environment
-
- - "Performance" device handlers, which provide in pseudo
-pass-through mode a way for direct
-performance measurements without overhead of actual data transferring
-from/to underlying SCSI device
-
-
-The latest stable version is 0.9.5.
-Requires Linux kernel 2.6.14 or higher.
-Tested mostly on i386 and x86_64,
-but should also
-work on any other
-supported by Linux platform. More detail information you could find in
-the project's README file.
-
-Starting from version 0.9.4 2.4 Linux
-kernels are not supported anymore. The latest
-stable
-version of SCST for 2.4 kernels is 0.9.3.1-24.
-If you have any questions you can ask
-them on the SCST SF.net page either using forum, or scst-devel mailing
-list.
-
-Download
-SCST SF.net project
-page
-Change Log
-Documentation: HTML, PDF, scst_user
-interface description
-Some nice SCST call graphs, created by Ming Zhang: init_scst, scst_cmd_thread, scst_mgmt_cmd_thread, scst_mgmt_thread
-The latest development version of SCST and target drivers is
-available directly from the
-project's SVN. The SCST release policy is to make stable releases
-twice a year, with the only exception if the current stable version
-contains a critical bug. Therefore on practice the development version
-in the SVN
-is usually more stable, than the "stable" one. You can access it using
-either web-based SVN
-repository viewer or using anonymous access:
- svn co https://scst.svn.sourceforge.net/svnroot/scst
-
-More information about accessing SVN repository may be found here.
-
-History of the pre-SVN SCST development is available in SCST CVS
-repository, which is accessible using web-based CVS
-repository viewer or anonymous CVS access.
-
-
-SCST administration utility
-
-SCST administration utility "scstadmin" is developed by Mark
-Buechler. With it you can manually or automatically using either plain
-text config file, or MySQL database configure every aspect of SCST, for
-instance as part of the system startup/shutdown, including
-enabling/disabling target mode on your target SCSI controller.
-
-Download
-
-
-ISCSI target driver iSCSI-SCST
-
-
-
ISCSI-SCST is a forked (with all respects) version of IET with
-updates to work over SCST as well as with many improvements and
-bugfixes. The reason of fork is that the necessary changes are
-intrusive and with the current IET merge policy, where only simple
-bugfix-like patches, which doesn't touch the core code, could be
-merged, it is very unlikely that they will be merged in the main IET
-trunk.
-
-
ISCSI-SCST has the following major advantages over the mainline IET:
-
-
- - It uses full SCST power without loosing any existing feature
-(except, maybe, "illegal" from SCSI specifications point of view MPIO).
-Namely, you can use with it:
-
-
- - Pass-through mode with one to many relationship, i.e. when
-multiple initiators can connect to the exported pass-through devices
-(see above). For instance, you can safely export your parallel SCSI
-tape or tape library 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
-relationship, so it is unsafe to use it in multiple initiators
-environments.
-
- - More advances devices visibility management, when different
-initiators can see different set of devices with different access
-permissions from the same target.
- - O_DIRECT, i.e. "BLOCKIO on files", 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.
- - With 4KB blocks you can forget about abysmal write performance
-caused by misaligned partitions. All modern OS'es, including Windows
-starting from, at least, Windows 2000, work perfectly with 4KB block
-devices without any additional storage or handling overhead.
- - Virtual CD/DVD-ROMs without necessity for manual patching.
- - Ability to create target devices emulators in the user space.
- - Ability to create multi-transport SCSI targets, which can export
-(possibly, the same) devices over multiple transports.
-
-
- - It has many code improvements and cleanups, including stability
-and iSCSI RFC violations fixes. If you are an IET user and consider IET
-problemless, I'm sorry for the bad news. IET works well only on "fast"
-paths and regularly used branches, in many other less used cases IET
-has various problems, from simply ignoring error processing, as it is
-with memory allocations, to crashing itself with BUG() macro, as it is
-for malformed packets from initiators. ChangeLog file lists most
-noticeable fixes, but there were a lot of many other smaller ones.
-
-
- - Due to its reworked IO architecture and SCST backend iSCSI-SCST
-has better performance in many cases. In future with upcoming SCST
-improvements, like zero-copy with Linux cache FILEIO, the performance
-difference is going to be even bigger. Currently in tests from a single
-initiator over a single connection on 1GbE hardware over FILEIO vdisk
-iSCSI-SCST with default settings usually outperforms tuned IET a on
-3-10% (by default IET has not too good settings, so it shows
-considerably worse results) or has the similar performance. The bigger
-difference is expected with 10GbE hardware or with higher number of
-initiators, since iSCSI-SCST has less commands processing overhead per
-command, hence put less load on CPU. If you find a case where
-iSCSI-SCST has worse performance, than IET, please report it to SCST
-mailing list scst-devel@lists.sourceforge.net, it will be greatly
-appreciated.
-
-
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. ISCSI-SCST is going to
-be actively developed and gain in the future new features like support
-for multiple connections per session, error recovery levels >0,
-etc., which eventually make it really "enterprise".
-
-
ISCSI-SCST is available for download from the SCST SVN repository. See
-above how to setup access to it.
-
-
After some testing for month-two, iSCSI-SCST is going to be fully
-released.
-
-
If you are an IET user, please, 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 are divided (as it
-should be) between the target driver (iSCSI-SCST) and the SCST core.
-The target driver is responsible for handling targets and their
-parameters, SCST core is responsible for handling backstorage.
-
-
-Target driver for QLogic 2200/2300 cards
-
-
-
This is ported and improved version of the "old" target driver for
-2.4 kernels (see below) to the in-tree 2.6 QLogic 2x00 initiator
-driver. The port was done by Nathaniel Clark. This is stable and
-functional driver with
-the larger feature set, than the parent driver has.
-
The latest version is 0.9.5. Requires
-Linux kernel version 2.6.16.x or higher and SCST version 0.9.5 or
-higher.
-Tested mostly on i386 and
-x86_64, but
-should work on any other supported by Linux platform.
-
-
You can find the latest development
-version of this driver in the SCST SVN. See above how to setup access
-to it.
-
-
Download
-Change Log
-
-
-Target driver for LSI/MPT cards
-Target driver LSI/MPT cards was originally developed by Hu Gang, then
-Erik Habbinga has continued the development. This driver is on the
-alpha stage and available for download from the SCST SVN repository. See
-above how to setup access to it.
-
-
-SCSI RDMA Protocol (SRP) Target driver
-SCSI RDMA Protocol (SRP) Target driver is developed
-independently from SCST team. You can find instructions how to download
-and install it on this page: http://lists.openfabrics.org/pipermail/iwg/2007-March/000378.html
-
-
-Target driver for QLogic ISP chipsets
-
-This is target driver for ISP QLogic chipsets commonly used in many
-SCSI and FC host bus adapters. Supported chipsets are listed in README
-file, incomplete list of supported HBA's is in doc/Hardware.txt. It is
-based on Matthew Jacob's multiplatform driver for ISP chipsets, which
-can be downloaded from ftp://ftp.feral.com/pub/isp/isp_dist.tgz.
-The update for SCST was made and supported by Stanislaw Gruszka.
-
-One major difference of this driver from the above target driver for
-QLogic 2200/2300 cards is that it supports 24xx series of chipsets.
-
-This driver is unstable and on the
-alpha stage. It is available for download from the SCST SVN repository. See
-above how to setup access to it.
-
-
-Old target driver for QLogic 2200/2300 cards for 2.4 kernels
-
-Old target driver for QLogic
-2200/2300
-cards is capable to work on 2.4 kernels. It has all required features
-and
-looks to be quite stable. It is designed to work in conjunction with
-the initiator
-driver, which is intended to perform all the initialization and
-shutdown tasks. In the current release as a base for the initiator
-driver was taken Red Hat's driver from the stock 2.4.20 kernel. Then it
-was patched to enable the target mode and provide all
-necessary callbacks, and it's still able to work as initiator only.
-Mode, when a host acts as the initiator and the target simultaneously,
-is also supported. This driver is obsoleted in favor of
-2.6-based driver (see above).
-
-The latest version is 0.9.3.4. Requires Linux kernel versions 2.4.20 or
-higher and SCST version 0.9.3-pre4 or higher. If you are lucky, it
-works also on 2.6 kernels, see README file
-for details. Tested on i386 only, but
-should work on any other supported by Linux platform.
-
-Currently it is not supported and listed here for historical reasons
-only.
-
-
-Download
-Change Log
-
-Target drivers for Adaptec 7xxx and QLogic QLA12xx
-cards
-Target drivers for Adaptec 7xxx and QLogic QLA12xx cards have
-been developed by Hu Gang and they available for download from http://bj.soulinfo.com/~hugang/scst/tgt/.
-These drivers are not completed, but looks to be a good starting point
-if you are going to use one of these cards.
-SCST team don't have the appropriate hardware, therefore have not
-tested and don't support these drivers. Send all questions to Hu Gang
-<hugang
-% soulinfo.com>. If some of these drivers don't compile for you, try
-again with SCST version 0.9.3-pre2.
-
-Download
-
-
-Patches for UNH-iSCSI Target 1.5.03 and 1.6.00 to work over
-SCST
-SCST is much more advanced, than the internal mid-level of UNH-iSCSI target
-driver.
-With SCST the iSCSI target benefits from all its features and gets
-ability to use all its advantages, like high performance and
-scalability, SMP support, required SCSI functionality emulation, etc.
-
-Since the interface between SCST and the target drivers is based on
-work, done by UNH IOL, it was relatively simple to update UNH-iSCSI
-target to work over SCST. Mostly it was "search and replace" job. The
-built-in scsi_target remains available as a compile-time option.
-
-Requires Linux kernel versions 2.4.20 or
-higher or 2.6.7 or higher and SCST version 0.9.2 or higher.
-
-Currently it is not supported and listed here for historical reasons
-only.
-
-Download
-
-
-
diff --git a/www/scstadmin.html b/www/scstadmin.html
new file mode 100644
index 000000000..06f097d00
--- /dev/null
+++ b/www/scstadmin.html
@@ -0,0 +1,26 @@
+
+
+
+
+ SCST: Generic SCSI Target Middle Level for Linux
+
+
+
+
+SCST administration utility
+
+SCST administration utility "scstadmin" is developed by Mark
+Buechler. With it you can manually or automatically using either plain
+text config file, or MySQL database configure every aspect of SCST, for
+instance as part of the system startup/shutdown, including
+enabling/disabling target mode on your target SCSI controller.
+
+Download
+released versions
+
+
+
+
diff --git a/www/targets.html b/www/targets.html
new file mode 100644
index 000000000..c322a5fd4
--- /dev/null
+++ b/www/targets.html
@@ -0,0 +1,171 @@
+
+
+
+
+ SCST: Generic SCSI Target Middle Level for Linux
+
+
+
+ISCSI target driver iSCSI-SCST
+
+
+
ISCSI-SCST is a forked (with all respects) version of IET with
+updates to work over SCST as well as with many improvements and
+bugfixes. The reason of fork is that the necessary changes are
+intrusive and with the current IET merge policy, where only simple
+bugfix-like patches, which doesn't touch the core code, could be
+merged, it is very unlikely that they will be merged in the main IET
+trunk.
+
+
ISCSI-SCST has the following major advantages over the mainline IET:
+
+
+ - It uses full SCST power without loosing any existing feature
+(except, maybe, "illegal" from SCSI specifications point of view MPIO).
+Namely, you can use with it:
+
+
+ - Pass-through mode with one to many relationship, i.e. when
+multiple initiators can connect to the exported pass-through devices.
+For instance, you can safely export your parallel SCSI
+tape or tape library 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
+relationship, so it is unsafe to use it in multiple initiators
+environments.
+
+ - More advances devices visibility management, when different
+initiators can see different set of devices with different access
+permissions from the same target.
+ - O_DIRECT, i.e. "BLOCKIO on files", 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.
+ - With 4KB blocks you can forget about abysmal write performance
+caused by misaligned partitions. All modern OS'es, including Windows
+starting from, at least, Windows 2000, work perfectly with 4KB block
+devices without any additional storage or handling overhead.
+ - Virtual CD/DVD-ROMs without necessity for manual patching.
+ - Ability to create target devices emulators in the user space.
+ - Ability to create multi-transport SCSI targets, which can export
+(possibly, the same) devices over multiple transports.
+
+
+ - It has many code improvements and cleanups, including stability
+and iSCSI RFC violations fixes. If you are an IET user and consider IET
+problemless, I'm sorry for the bad news. IET works well only on "fast"
+paths and regularly used branches, in many other less used cases IET
+has various problems, from simply ignoring error processing, as it is
+with memory allocations, to crashing itself with BUG() macro, as it is
+for malformed packets from initiators. ChangeLog file lists most
+noticeable fixes, but there were a lot of many other smaller ones.
+
+
+ - Due to its reworked IO architecture and SCST backend iSCSI-SCST
+has better performance in many cases. In future with upcoming SCST
+improvements, like zero-copy with Linux cache FILEIO, the performance
+difference is going to be even bigger. Currently in tests from a single
+initiator over a single connection on 1GbE hardware over FILEIO vdisk
+iSCSI-SCST with default settings usually outperforms tuned IET a on
+3-10% (by default IET has not too good settings, so it shows
+considerably worse results) or has the similar performance. The bigger
+difference is expected with 10GbE hardware or with higher number of
+initiators, since iSCSI-SCST has less commands processing overhead per
+command, hence has smaller processing latency and puts less load on
+CPU. If you find a case where
+iSCSI-SCST has worse performance, than IET, please report it to SCST
+mailing list, it will be greatly
+appreciated.
+
+
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. ISCSI-SCST is going to
+be actively developed and gain in the future new features like support
+for multiple connections per session, error recovery levels >0,
+etc., which eventually make it really "enterprise".
+
+
ISCSI-SCST is available for download from the SCST SVN repository. See
+the main page how to setup access to it.
+
+
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 are divided (as it
+should be) between the target driver (iSCSI-SCST) and the SCST core:
+target driver is responsible for handling targets and their
+parameters, SCST core is responsible for handling backstorage.
+
+
+Target driver for QLogic 22xx/23xx
+cards
+
+
+
This is target driver for QLogic 22xx/23xx Fibre Channel cards, but
+24xx and later cards are not supported by it.
+
+
The latest version is 0.9.5. Requires
+Linux kernel version 2.6.16.x or higher and SCST version 0.9.5 or
+higher.
+Tested mostly on i386 and
+x86_64, but
+should work on any other supported by Linux platform.
+
+
You can find the latest development
+version of this driver in the SCST SVN. See the main
+page how to setup access to it.
+
+
Download
+released versions
+Change Log
+
+
+Target driver for QLogic ISP chipsets
+
+This is target driver for ISP QLogic chipsets commonly used in many
+SCSI and FC host bus adapters. Supported chipsets are listed in README
+file, incomplete list of supported HBA's is in doc/Hardware.txt. It is
+based on Matthew Jacob's multiplatform driver for ISP chipsets, which
+can be downloaded from ftp://ftp.feral.com/pub/isp/isp_dist.tgz.
+The update for SCST was made and supported by Stanislaw Gruszka.
+
+One major difference of this driver from the above target driver for
+QLogic 2200/2300 cards is that it supports 24xx series of chipsets.
+
+This driver is unstable and on the
+alpha stage. It is available for download from the SCST SVN repository. See
+the main page how to setup access to it.
+
+
+Infiniband SCSI RDMA Protocol (SRP)
+Target driver
+SCSI RDMA Protocol (SRP) target driver is developed
+independently from SCST team. You can find instructions how to download
+and install it on its wiki
+page
+
+
+Target driver for LSI/MPT cards
+Target driver LSI/MPT cards was originally developed by Hu Gang, then
+Erik Habbinga has continued the development. It supports parallel SCSI
+(SPI), but also should work with SAS and Fibre Channel transports. This
+driver is
+on the
+alpha stage and available for download from the SCST SVN repository. See
+the main page how to setup access to it.
+
+
+
