[ANNOUNCE] Generic SCSI Target Middle Level for Linux (SCST) with target drivers

[ANNOUNCE] Generic SCSI Target Middle Level for Linux (SCST) with target drivers

[Vladislav Bolkhovitin]

I would like to announce the first public release of a generic SCSI
target middle level subsystem for Linux (SCST) with Qlogic 2200/2300
target driver and a patch for for UNH-iSCSI Target 1.5.3 to work over
SCST.

SCST is designed to provide unified, consistent interface between SCSI
target drivers and Linux kernel and simplify target drivers development
as much as possible. It has the following features:

  - Very low overhead, fine-grained locks and simplest commands
    processing path, which allow to reach maximum possible performance
    and scalability that close to theoretical limit.

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

  - Complete SMP support.

  - 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 about 2000
    lines of code long, that is at least in several times less, than
    the initiator one.

  - Performs all required pre- and post- processing of incoming
    requests and all necessary error recovery functionality.

  - Emulates necessary functionality of SCSI host adapter, because from
    a remote initiator's point of view SCST acts as a SCSI host with
    its own devices. Some of the emulated functions are the following:

     o  Generation of necessary UNIT ATTENTIONs, their storage and
        delivery to all connected remote initiators (sessions).

     o  RESERVE/RELEASE functionality.

     o  CA/ACA conditions.

     o  All types of RESETs and other task management functions.

     o  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 (not implemented yet), so different remote
        initiators could see different set of devices.

     o  Other necessary functionality (task attributes, etc.) as
        specified in SAM-2, SPC-2, SAM-3, SPC-3 and other SCSI
        standards.

  - Device handlers architecture provides extra reliability and security
    via verifying all incoming requests and allows to make any
    additional requests processing, which is completely independent
    from target drivers, for example, device dependent exceptional
    conditions treatment or data caching.

Interoperability between SCST and local SCSI initiators (like sd, st) 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 would be done behind SCST, which could lead
to various problems. 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
InterOperability Lab (IOL) of University of New Hampshier (UNH).

In addition, the project contains a target driver for Qlogic 2200/2300
Fibre Channel cards and a patch for for UNH-iSCSI Target 1.5.3 that
makes it work over SCST.

In the current version 0.9.1 SCST looks to be quite stable (for beta)
and useful. The same is for Qlogic 2200/2300 target driver. Only 2.4
kernels currently supported, but update for 2.6 is coming soon. No
kernel patches are necessary. Tested on i386 only, but should work on
any other supported by Linux platform.

More information, including the source code and detail documentation, 
could be found on http://scst.sf.net.

Any comments would be appreciated.

Vlad

Re: [ANNOUNCE] Generic SCSI Target Middle Level for Linux (SCST) with target drivers

[Matthew Wilcox]

On Wed, Jun 16, 2004 at 08:31:22PM +0400, Vladislav Bolkhovitin wrote:
> Any comments would be appreciated.

The first obvious question is: Why does this need to be done in kernel
space?  My impression was that an iSCSI target would best be done in
userspace.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [ANNOUNCE] Generic SCSI Target Middle Level for Linux (SCST) with target drivers

[Vladislav Bolkhovitin]

Matthew Wilcox wrote:
> On Wed, Jun 16, 2004 at 08:31:22PM +0400, Vladislav Bolkhovitin wrote:
> 
>>Any comments would be appreciated.
> 
> 
> The first obvious question is: Why does this need to be done in kernel
> space?  My impression was that an iSCSI target would best be done in
> userspace.
> 
The answer is quite obvious as well. There is not only iSCSI target 
(i.e. software one) in the world. For hardware targets if you were 
switch on each command (IRQ) to user space and back, it would be huge 
performance penalty, especially for commands that request small data 
transfers. Take a look on the Qlogic target: all job is done in the 
tasklet, without ever context switch. The same is for upcoming iSCSI 
hardware, like Qlogic QLA4010, which also supports target mode.

BTW, the processing is simple enough, the main SCST module is only about 
  60Kb long. The main point is that this processing must be done in 
_each_ SCSI target driver. So, consider SCSI target mid-level like a 
library (framework) for such drivers, exectly as the regular SCSI 
mid-level for regular SCSI drivers.

Thanks,
Vlad

Re: [ANNOUNCE] Generic SCSI Target Middle Level for Linux (SCST) with target drivers

[Christoph Hellwig]

On Wed, Jun 16, 2004 at 08:31:22PM +0400, Vladislav Bolkhovitin wrote:
> In the current version 0.9.1 SCST looks to be quite stable (for beta)
> and useful. The same is for Qlogic 2200/2300 target driver. Only 2.4
> kernels currently supported, but update for 2.6 is coming soon. No
> kernel patches are necessary. Tested on i386 only, but should work on
> any other supported by Linux platform.
> 
> More information, including the source code and detail documentation, 
> could be found on http://scst.sf.net.
> 
> Any comments would be appreciated.

The code looks pretty neat to me, there's a few issues I'd like to see
addresses but that doesn't make sense before the 2.4 support is dropped
and there's an actual LLDD for 2.6.  But I think for most interesting
scenarios in the storage virtualization world your driver is pretty much
useless because it wants to dispatch directly to a scsi device and doesn't
go through the block layer.  So no fancy volume managers/etc there to make
interesting storage virtualization boxes.

Re: [ANNOUNCE] Generic SCSI Target Middle Level for Linux (SCST) with target drivers

[Vladislav Bolkhovitin]

Christoph Hellwig wrote:
> On Wed, Jun 16, 2004 at 08:31:22PM +0400, Vladislav Bolkhovitin wrote:
> 
  > The code looks pretty neat to me, there's a few issues I'd like to see
> addresses but that doesn't make sense before the 2.4 support is dropped
> and there's an actual LLDD for 2.6.  But I think for most interesting
> scenarios in the storage virtualization world your driver is pretty much
> useless because it wants to dispatch directly to a scsi device and doesn't
> go through the block layer.  So no fancy volume managers/etc there to make
> interesting storage virtualization boxes.
> 
For that is intended upcoming block device handler with block 
layer/cache support,
which will be in its exec() method check, if requested blocks in cache, 
and, if not, dispatch the commands to block layer, leaving regular 
scsi_do_req() calls for tapes, changers, etc. In the similar way "_perf" 
handlers work (they don't send READ/WRITE commands to SCSI devices for 
performance studies).

This device handler is on our todo list. Actually, it's quite simple and 
if anyone interested, he's help would be greatly appreciated.

Thanks,
Vlad