|
|
|
|
@@ -13,7 +13,7 @@ SCST's Internet page http://scst.sourceforge.net.
|
|
|
|
|
SCST looks to be quite stable (for beta) and useful. It supports disks
|
|
|
|
|
(SCSI type 0), tapes (type 1), processor (type 3), CDROM's (type 5), MO
|
|
|
|
|
disks (type 7), medium changers (type 8) and RAID controller (type 0xC)
|
|
|
|
|
as well as FILEIO and "performance" device handlers. In addition, it
|
|
|
|
|
as well as VDISK and "performance" device handlers. In addition, it
|
|
|
|
|
supports advanced per-initiator access and devices visibility
|
|
|
|
|
management, so different initiators could see different set of devices
|
|
|
|
|
with different access permissions. See below for details.
|
|
|
|
|
@@ -34,7 +34,7 @@ new functions scsi_do_req_fifo()/scsi_execute_async_fifo() to be added
|
|
|
|
|
in the kernel. Patch 26_scst-2.6.X.patch from "kernel" directory does
|
|
|
|
|
that. If it doesn't apply to your kernel, apply it manually, it only
|
|
|
|
|
adds one of those functions and nothing more. You may not patch the
|
|
|
|
|
kernel if STRICT_SERIALIZING or FILEIO_ONLY are defined during the
|
|
|
|
|
kernel if STRICT_SERIALIZING or VDISK_ONLY are defined during the
|
|
|
|
|
compilation (see their description below).
|
|
|
|
|
|
|
|
|
|
To compile SCST type 'make'. It will build SCST itself and its device
|
|
|
|
|
@@ -55,7 +55,7 @@ Then you can load any module by typing 'modprobe drive_name'. The names are:
|
|
|
|
|
- scst_modisk - device handler for MO disks (type 7)
|
|
|
|
|
- scst_changer - device handler for medium changers (type 8)
|
|
|
|
|
- scst_raid - device handler for storage array controller (e.g. raid) (type C)
|
|
|
|
|
- scst_fileio - device handler for FILE IO (disk or ISO CD image).
|
|
|
|
|
- scst_vdisk - device handler for virtual disks (disk or ISO CD image).
|
|
|
|
|
|
|
|
|
|
Then, to see your devices remotely, you need to add them to at least
|
|
|
|
|
"Default" security group (see below how). By default, no local devices
|
|
|
|
|
@@ -97,10 +97,10 @@ for a SCSI device type isn't loaded, SCST doesn't know how to handle
|
|
|
|
|
devices of this type, so they will be invisible for remote initiators
|
|
|
|
|
(more precisely, "LUN not supported" sense code will be returned).
|
|
|
|
|
|
|
|
|
|
In addition to device handlers for real devices, there are FILEIO and
|
|
|
|
|
In addition to device handlers for real devices, there are VDISK and
|
|
|
|
|
"performance" ones.
|
|
|
|
|
|
|
|
|
|
FILEIO device handler works over files on file systems and makes from
|
|
|
|
|
VDISK device handler works over files on file systems and makes from
|
|
|
|
|
them virtual remotely available SCSI disks or CDROM's. In addition, it
|
|
|
|
|
allows to work directly over a block device, e.g. local IDE or SCSI disk
|
|
|
|
|
or ever disk partition, where there is no file systems overhead. Using
|
|
|
|
|
@@ -111,7 +111,7 @@ caching and read ahead performed by Linux's VM subsystem. The only
|
|
|
|
|
disadvantage here that there is superfluous data copying between the
|
|
|
|
|
cache and SCST's buffers. This issue is going to be addressed in the
|
|
|
|
|
next release. Virtual CDROM's are useful for remote installation. See
|
|
|
|
|
below for details how to setup and use FILEIO device handler.
|
|
|
|
|
below for details how to setup and use VDISK device handler.
|
|
|
|
|
|
|
|
|
|
"Performance" device handlers for disks, MO disks and tapes in their
|
|
|
|
|
exec() method skip (pretend to execute) all READ and WRITE operations
|
|
|
|
|
@@ -129,7 +129,7 @@ Compilation options
|
|
|
|
|
There are the following compilation options, that could be commented
|
|
|
|
|
in/out in Makefile:
|
|
|
|
|
|
|
|
|
|
- FILEIO_ONLY - if defined, the pass-through device handlers
|
|
|
|
|
- VDISK_ONLY - if defined, the pass-through device handlers
|
|
|
|
|
(scst_disk, scst_tape) will not work, but SCST will not require the
|
|
|
|
|
kernel patching. Defined by default to ease new people try SCST on
|
|
|
|
|
their kernels.
|
|
|
|
|
@@ -288,27 +288,27 @@ Examples:
|
|
|
|
|
group with LUN 0.
|
|
|
|
|
|
|
|
|
|
- "echo "add disk1 1" >/proc/scsi_tgt/groups/Default/devices" will
|
|
|
|
|
add virtual FILEIO device with name "disk1" to "Default" group
|
|
|
|
|
add virtual VDISK device with name "disk1" to "Default" group
|
|
|
|
|
with LUN 1.
|
|
|
|
|
|
|
|
|
|
FILEIO device handler
|
|
|
|
|
---------------------
|
|
|
|
|
VDISK device handler
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
After loading FILEIO device handler creates in "/proc/scsi_tgt/"
|
|
|
|
|
subdirectories "disk_fileio" and "cdrom_fileio". They have similar layout:
|
|
|
|
|
After loading VDISK device handler creates in "/proc/scsi_tgt/"
|
|
|
|
|
subdirectories "vdisk" and "vcdrom". They have similar layout:
|
|
|
|
|
|
|
|
|
|
- "trace_level" and "type" files as described for other dev handlers
|
|
|
|
|
|
|
|
|
|
- "help" file, which provides online help for FILEIO commands
|
|
|
|
|
- "help" file, which provides online help for VDISK commands
|
|
|
|
|
|
|
|
|
|
- "disk_fileio"/"cdrom_fileio" files, which on read provides
|
|
|
|
|
information of currently open device files. On write it supports the
|
|
|
|
|
following command:
|
|
|
|
|
- "vdisk"/"vcdrom" files, which on read provides information of
|
|
|
|
|
currently open device files. On write it supports the following
|
|
|
|
|
command:
|
|
|
|
|
|
|
|
|
|
* "open NAME [PATH] [BLOCK_SIZE] [FLAGS]" - opens file "PATH" as
|
|
|
|
|
device "NAME" with block size "BLOCK_SIZE" bytes with flags
|
|
|
|
|
"FLAGS". "PATH" could be empty only for FILEIO CDROM. "BLOCK_SIZE"
|
|
|
|
|
and "FLAGS" are valid only for disk FILEIO. The block size must be
|
|
|
|
|
"FLAGS". "PATH" could be empty only for VDISK CDROM. "BLOCK_SIZE"
|
|
|
|
|
and "FLAGS" are valid only for disk VDISK. The block size must be
|
|
|
|
|
power of 2 and >= 512 bytes Default is 512. Possible flags:
|
|
|
|
|
|
|
|
|
|
- WRITE_THROUGH - write back caching disabled
|
|
|
|
|
@@ -340,12 +340,12 @@ subdirectories "disk_fileio" and "cdrom_fileio". They have similar layout:
|
|
|
|
|
|
|
|
|
|
* "close NAME" - closes device "NAME".
|
|
|
|
|
|
|
|
|
|
* "change NAME [PATH]" - changes a virtual CD in the FILEIO CDROM.
|
|
|
|
|
* "change NAME [PATH]" - changes a virtual CD in the VDISK CDROM.
|
|
|
|
|
|
|
|
|
|
For example, "echo "open disk1 /vdisks/disk1" >/proc/scsi_tgt/disk_fileio/disk_fileio"
|
|
|
|
|
will open file /vdisks/disk1 as virtual FILEIO disk with name "disk1".
|
|
|
|
|
For example, "echo "open disk1 /vdisks/disk1" >/proc/scsi_tgt/vdisk/vdisk"
|
|
|
|
|
will open file /vdisks/disk1 as virtual VDISK disk with name "disk1".
|
|
|
|
|
|
|
|
|
|
IMPORTANT: By default for performance reasons FILEIO devices use write back
|
|
|
|
|
IMPORTANT: By default for performance reasons VDISK devices use write back
|
|
|
|
|
========= caching policy. This is generally safe from the consistence of
|
|
|
|
|
journaled file systems, laying over them, point of view, but
|
|
|
|
|
your unsaved cached data will be lost in case of
|
|
|
|
|
@@ -390,13 +390,13 @@ Before doing any performance measurements note that:
|
|
|
|
|
|
|
|
|
|
I. Currently maximum performance is possible only with real SCSI devices
|
|
|
|
|
with several simultaneously executed commands (SCSI tagged queuing) or
|
|
|
|
|
performance handlers. If you have enough CPU power, FILEIO handler also
|
|
|
|
|
performance handlers. If you have enough CPU power, VDISK handler also
|
|
|
|
|
could provide the same results, when aggregate throughput is close to
|
|
|
|
|
the aggregate throughput locally on the target from the same disks. Also
|
|
|
|
|
note, that currently IO subsystem in Linux implemented on such way, so a
|
|
|
|
|
FILEIO device over a single file occupied entire formatted with some
|
|
|
|
|
VDISK device over a single file occupied entire formatted with some
|
|
|
|
|
file system device (eg /dev/hdc) could perform considerably better, than
|
|
|
|
|
a FILEIO device over /dev/hdc itself without the file system involved.
|
|
|
|
|
a VDISK device over /dev/hdc itself without the file system involved.
|
|
|
|
|
|
|
|
|
|
II. In order to get the maximum performance you should:
|
|
|
|
|
|
|
|
|
|
@@ -409,7 +409,7 @@ II. In order to get the maximum performance you should:
|
|
|
|
|
|
|
|
|
|
- Disable in Makefile EXTRACHECKS, TRACING, DEBUG_TGT, DEBUG_WORK_IN_THREAD
|
|
|
|
|
|
|
|
|
|
3. For device handlers, including FILEIO:
|
|
|
|
|
3. For device handlers, including VDISK:
|
|
|
|
|
|
|
|
|
|
- Disable in Makefile TRACING, DEBUG
|
|
|
|
|
|
|
|
|
|
@@ -445,13 +445,13 @@ IMPORTANT: Some of those options enabled by default, i.e. SCST is optimized
|
|
|
|
|
expected.
|
|
|
|
|
|
|
|
|
|
IMPORTANT: If you use on initiator some versions of Windows (at least W2K)
|
|
|
|
|
========= you can't get good write performance for FILEIO devices with
|
|
|
|
|
========= you can't get good write performance for VDISK devices with
|
|
|
|
|
default 512 bytes block sizes. You could get about 10% of the
|
|
|
|
|
expected one. This is because of "unusual" write access
|
|
|
|
|
pattern, with which Windows'es write data and which is
|
|
|
|
|
(simplifying) incompatible with how Linux page cache works,
|
|
|
|
|
so for each write the corresponding block must be read first.
|
|
|
|
|
With 4096 bytes block sizes for FILEIO devices the write
|
|
|
|
|
With 4096 bytes block sizes for VDISK devices the write
|
|
|
|
|
performance will be as expected. Actually, any system on
|
|
|
|
|
initiator, not only Windows, will benefit from block size
|
|
|
|
|
max(PAGE_SIZE, BLOCK_SIZE_ON_UNDERLYING_FS), where PAGE_SIZE
|
|
|
|
|
|
Vladislav Bolkhovitin