Generic SCSI Target Middle Level for Linux
The SCSI target mid-level subsystem for Linux (SCST) is an alternative implementation of SCSI target subsystem for Linux. It provides unified, consistent interface between SCSI target drivers and Linux kernel and simplifies target drivers development.
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 project consists from a set of subprojects: SCST core itself with a set of device handlers as well as target drivers and user space utilities.
Features of SCST Core
- Simple, easy to use interface with target drivers. Particularly, SCST core performs required pre- and post- processing of incoming requests as well as 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 22xx/23xx cards, which has all necessary features, is only about 2000 lines of code long. The same is true for InfiniBand SRP target driver.
- 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 core's tasklets without any extra context switches.
- 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 X and Y read-writable, and initiator B from the same target T could see devices Y read-only and Z 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 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.
- 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 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.
- Multithreaded design and complete SMP support, so, if necessary, all your processors will participate in the commands processing.
- Well documented.
Interoperability between SCST core 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 core 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 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).
- 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.
