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 devices can use any link which supports SCSI-style data exchange: iSCSI, Fibre Channel, FCoE, SAS, InfiniBand (SRP), Wide (parallel) SCSI, etc.
It might well be that your favorite storage appliance is 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 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 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.
- Device handlers architecture allows various I/O modes in backstorage handling. For example, pass-through device handlers allow to export real SCSI hardware and vdisk device handler allows to export 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 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 high performance virtual SCSI devices. Comparing with fully in-kernel dev handlers this mode has very low overhead (few %%).
- Performance testing device handlers as well as NULLIO mode to provide a way for direct performance measurements without overhead of actual data transfers from/to underlying SCSI devices.
SCST core engine has passed VMware certification as part of Scale’s Intelligent Clustered Storage technology developed by Scale Computing as well as VMware and Microsoft certification as part of storage arrays developed by Open-E, Inc and Starboard Storage.
As of October 2012 SCST-based Hewlett-Packard ProLiant BL465c Gen8 earned the maximum score 59.99@62 tiles in VMmark Version 2.1.1.