Generic SCSI Target Subsystem for Linux

Generic SCSI Target Subsystem for Linux

The generic SCSI target subsystem for Linux (SCST) allows creation of sophisticated storage devices
from any Linux box. Those
devices can provide advanced
functionality, like replication, thin provisioning,
deduplication, high availability,
automatic backup, etc. Another class of such devices
are Virtual Tape Libraries (VTL)
as well as other disk-based backup solutions.

SCST core performs all required pre- and post- processing of incoming requests as well as
necessary error recovery.

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 Marvell
SAS adapters or for InfiniBand SRP are less 3000 lines of code long.

Very low overhead and fine-grained locks allow to reach the
maximum performance and scalability. Particularly, incoming requests can be processed in
the caller's context or in one of the internal SCST core's tasklets without any
extra context switches.

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

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 this
message in thread "Question for pass-through target design" 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.

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 core responds with error on all
commands to non-existing devices and provides access control, so different remote
initiators could see different set of devices.

SCST core has multithreaded design and complete SMP support, so, if necessary, all your CPU cores will participate in the commands
processing.

Well documented.

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, 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 passed through SCST core.

You can find comparison of SCST with other SCSI targets on the Comparison page.
Some highlights what it can mean for end users you can find on the iSCSI-SCST page.

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

BLOCKIO mode, 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.