Generic SCSI Target Subsystem for Linux

The generic SCSI target subsystem for Linux (SCST) is an alternative implementation of a SCSI target subsystem for Linux. It provides unified, consistent interface between SCSI target drivers and Linux kernel as well as between Linux kernel and storage backend handlers, connecting target drivers with real or emulated storage backend.

SCST allows creation of sophisticated storage devices, which 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 created devices not limited by IP networking only. They can use any link which supports SCSI-style data exchange, including Fibre Channel, iSCSI, SAS, InfiniBand and parallel (Wide) SCSI. It might well be that your favorite storage appliance running SCST in the firmware.

SCST project consists from a set of subprojects: generic SCSI target mid-layer itself (SCST core) with a set of device handlers as well as target drivers and user space utilities.

Features of SCST Core

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.
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, fine-grained locks and simplest commands processing path 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 core's tasklets without any extra context switches.
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.
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.
- Other necessary functionality (task attributes, etc.) as specified in SAM-2, SPC-2, SAM-3, SPC-3 and other SCSI standards.
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.

SCST core 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). In this mode you can, for instance, share your parallel SCSI tape or SATA DVD-RW device to your iSCSI network.
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.
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 as well as NULLIO mode provide a way for direct performance measurements without overhead of actual data transferring from/to underlying SCSI device.