mirror of
https://github.com/SCST-project/scst.git
synced 2026-08-18 21:26:31 +00:00
- SysfsRules file added
- Other docs updated - ini_group renamed to ini_groups git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1542 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Vladislav Bolkhovitin
+8
-8
@@ -172,7 +172,7 @@ which attributes it should save in the config file. You can ignore it.
|
||||
|
||||
Each target subdirectory contains the following entries:
|
||||
|
||||
- ini_group - subdirectory defining initiator groups for this target,
|
||||
- ini_groups - subdirectory defining initiator groups for this target,
|
||||
used to define per-initiator access control. See SCST core README for
|
||||
more details.
|
||||
|
||||
@@ -327,9 +327,9 @@ echo "32" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/QueuedCo
|
||||
echo "add disk2 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/luns/mgmt
|
||||
echo "add nullio 26" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/luns/mgmt
|
||||
|
||||
echo "create special_ini" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/mgmt
|
||||
echo "add blockio 0 read_only=1" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/special_ini/luns/mgmt
|
||||
echo "add iqn.2005-03.org.open-iscsi:cacdcd2520" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/special_ini/initiators/mgmt
|
||||
echo "create special_ini" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/mgmt
|
||||
echo "add blockio 0 read_only=1" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/special_ini/luns/mgmt
|
||||
echo "add iqn.2005-03.org.open-iscsi:cacdcd2520" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/special_ini/initiators/mgmt
|
||||
|
||||
echo 1 >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt/enabled
|
||||
echo 1 >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/enabled
|
||||
@@ -344,7 +344,7 @@ both iSCSI-SCST targets will look like:
|
||||
| |-- blockio
|
||||
| | |-- blocksize
|
||||
| | |-- exported
|
||||
| | | `-- export0 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/special_ini/luns/0
|
||||
| | | `-- export0 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/special_ini/luns/0
|
||||
| | |-- filename
|
||||
| | |-- handler -> ../../handlers/vdisk_blockio
|
||||
| | |-- read_only
|
||||
@@ -454,7 +454,7 @@ both iSCSI-SCST targets will look like:
|
||||
| | |-- MaxXmitDataSegmentLength
|
||||
| | |-- QueuedCommands
|
||||
| | |-- enabled
|
||||
| | |-- ini_group
|
||||
| | |-- ini_groups
|
||||
| | | `-- mgmt
|
||||
| | |-- luns
|
||||
| | | |-- 0
|
||||
@@ -503,7 +503,7 @@ both iSCSI-SCST targets will look like:
|
||||
| | |-- OutgoingUser
|
||||
| | |-- QueuedCommands
|
||||
| | |-- enabled
|
||||
| | |-- ini_group
|
||||
| | |-- ini_groups
|
||||
| | | |-- mgmt
|
||||
| | | `-- special_ini
|
||||
| | | |-- initiators
|
||||
@@ -542,7 +542,7 @@ both iSCSI-SCST targets will look like:
|
||||
| | | |-- commands
|
||||
| | | |-- force_close
|
||||
| | | |-- initiator_name
|
||||
| | | |-- luns -> ../../ini_group/special_ini/luns
|
||||
| | | |-- luns -> ../../ini_groups/special_ini/luns
|
||||
| | | |-- reinstating
|
||||
| | | `-- sid
|
||||
| | `-- tid
|
||||
|
||||
@@ -83,7 +83,7 @@ which attributes it should save in the config file. You can ignore it.
|
||||
|
||||
Each target subdirectory contains the following entries:
|
||||
|
||||
- ini_group - subdirectory defining initiator groups for this target,
|
||||
- ini_groups - subdirectory defining initiator groups for this target,
|
||||
used to define per-initiator access control. See SCST core README for
|
||||
more details.
|
||||
|
||||
@@ -238,9 +238,9 @@ echo "32" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/QueuedCo
|
||||
echo "add disk2 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/luns/mgmt
|
||||
echo "add nullio 26" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/luns/mgmt
|
||||
|
||||
echo "create special_ini" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/mgmt
|
||||
echo "add blockio 0 read_only=1" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/special_ini/luns/mgmt
|
||||
echo "add iqn.2005-03.org.open-iscsi:cacdcd2520" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/special_ini/initiators/mgmt
|
||||
echo "create special_ini" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/mgmt
|
||||
echo "add blockio 0 read_only=1" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/special_ini/luns/mgmt
|
||||
echo "add iqn.2005-03.org.open-iscsi:cacdcd2520" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/special_ini/initiators/mgmt
|
||||
|
||||
echo 1 >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt/enabled
|
||||
echo 1 >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/enabled
|
||||
@@ -255,7 +255,7 @@ both iSCSI-SCST targets will look like:
|
||||
| |-- blockio
|
||||
| | |-- blocksize
|
||||
| | |-- exported
|
||||
| | | `-- export0 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/special_ini/luns/0
|
||||
| | | `-- export0 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/special_ini/luns/0
|
||||
| | |-- filename
|
||||
| | |-- handler -> ../../handlers/vdisk_blockio
|
||||
| | |-- read_only
|
||||
@@ -365,7 +365,7 @@ both iSCSI-SCST targets will look like:
|
||||
| | |-- MaxXmitDataSegmentLength
|
||||
| | |-- QueuedCommands
|
||||
| | |-- enabled
|
||||
| | |-- ini_group
|
||||
| | |-- ini_groups
|
||||
| | | `-- mgmt
|
||||
| | |-- luns
|
||||
| | | |-- 0
|
||||
@@ -414,7 +414,7 @@ both iSCSI-SCST targets will look like:
|
||||
| | |-- OutgoingUser
|
||||
| | |-- QueuedCommands
|
||||
| | |-- enabled
|
||||
| | |-- ini_group
|
||||
| | |-- ini_groups
|
||||
| | | |-- mgmt
|
||||
| | | `-- special_ini
|
||||
| | | |-- initiators
|
||||
@@ -453,7 +453,7 @@ both iSCSI-SCST targets will look like:
|
||||
| | | |-- commands
|
||||
| | | |-- force_close
|
||||
| | | |-- initiator_name
|
||||
| | | |-- luns -> ../../ini_group/special_ini/luns
|
||||
| | | |-- luns -> ../../ini_groups/special_ini/luns
|
||||
| | | |-- reinstating
|
||||
| | | `-- sid
|
||||
| | `-- tid
|
||||
|
||||
@@ -184,7 +184,7 @@ Each target subdirectory contains the following entries:
|
||||
- host - link pointing on the corresponding scsi_host of the initiator
|
||||
driver
|
||||
|
||||
- ini_group - subdirectory defining initiator groups for this target,
|
||||
- ini_groups - subdirectory defining initiator groups for this target,
|
||||
used to define per-initiator access control. See SCST core README for
|
||||
more details.
|
||||
|
||||
@@ -259,10 +259,10 @@ echo "add blockio 0 read_only=1" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00
|
||||
echo "add nullio 1" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/luns/mgmt
|
||||
echo "add cdrom 2" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/luns/mgmt
|
||||
|
||||
echo "create 25:00:00:f0:99:87:94:a3" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_group/mgmt
|
||||
echo "add disk1 0" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_group/25:00:00:f0:99:87:94:a3/luns/mgmt
|
||||
echo "add disk2 1" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_group/25:00:00:f0:99:87:94:a3/luns/mgmt
|
||||
echo "add 25:00:00:f0:99:87:94:a3" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_group/25:00:00:f0:99:87:94:a3/initiators/mgmt
|
||||
echo "create 25:00:00:f0:99:87:94:a3" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_groups/mgmt
|
||||
echo "add disk1 0" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_groups/25:00:00:f0:99:87:94:a3/luns/mgmt
|
||||
echo "add disk2 1" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_groups/25:00:00:f0:99:87:94:a3/luns/mgmt
|
||||
echo "add 25:00:00:f0:99:87:94:a3" >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_groups/25:00:00:f0:99:87:94:a3/initiators/mgmt
|
||||
|
||||
echo 1 >/sys/kernel/scst_tgt/targets/qla2x00t/25:00:00:f0:98:87:92:f3/enabled
|
||||
|
||||
@@ -296,7 +296,7 @@ The resulting overall SCST sysfs hierarchy with initiator
|
||||
| |-- disk1
|
||||
| | |-- blocksize
|
||||
| | |-- exported
|
||||
| | | `-- export0 -> ../../../targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_group/25:00:00:f0:99:87:94:a3/luns/0
|
||||
| | | `-- export0 -> ../../../targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_groups/25:00:00:f0:99:87:94:a3/luns/0
|
||||
| | |-- filename
|
||||
| | |-- handler -> ../../handlers/vdisk_fileio
|
||||
| | |-- nv_cache
|
||||
@@ -312,7 +312,7 @@ The resulting overall SCST sysfs hierarchy with initiator
|
||||
| |-- disk2
|
||||
| | |-- blocksize
|
||||
| | |-- exported
|
||||
| | | `-- export0 -> ../../../targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_group/25:00:00:f0:99:87:94:a3/luns/1
|
||||
| | | `-- export0 -> ../../../targets/qla2x00t/25:00:00:f0:98:87:92:f3/ini_groups/25:00:00:f0:99:87:94:a3/luns/1
|
||||
| | |-- filename
|
||||
| | |-- handler -> ../../handlers/vdisk_fileio
|
||||
| | |-- nv_cache
|
||||
@@ -372,7 +372,7 @@ The resulting overall SCST sysfs hierarchy with initiator
|
||||
| | |-- enabled
|
||||
| | |-- explicit_confirmation
|
||||
| | |-- host -> ../../../../../class/scsi_host/host4
|
||||
| | |-- ini_group
|
||||
| | |-- ini_groups
|
||||
| | | |-- 25:00:00:f0:99:87:94:a3
|
||||
| | | | |-- initiators
|
||||
| | | | | |-- 25:00:00:f0:99:87:94:a3
|
||||
@@ -403,7 +403,7 @@ The resulting overall SCST sysfs hierarchy with initiator
|
||||
| | |-- active_commands
|
||||
| | |-- commands
|
||||
| | |-- initiator_name
|
||||
| | `-- luns -> ../../ini_group/25:00:00:f0:99:87:94:a3/luns
|
||||
| | `-- luns -> ../../ini_groups/25:00:00:f0:99:87:94:a3/luns
|
||||
| |-- trace_level
|
||||
| `-- version
|
||||
|-- threads
|
||||
|
||||
+66
-24
@@ -648,6 +648,11 @@ documentation for your dev handlers for more info about it as well as
|
||||
SysfsRules file for more info about common to all dev handlers rules.
|
||||
Standard SCST dev handlers have at least the following common entries:
|
||||
|
||||
- mgmt - this entry allows to create virtual devices and their
|
||||
attributes (for virtual devices dev handlers) or assign/unassign real
|
||||
SCSI devices to/from this dev handler (for pass-through dev
|
||||
handlers).
|
||||
|
||||
- pass_through - if exists, it contains 1 and this dev handler is a
|
||||
pass-through dev handler.
|
||||
|
||||
@@ -674,10 +679,10 @@ Each SGV cache's subdirectory has the following item:
|
||||
|
||||
Content of each target's subdirectory is target specific. See
|
||||
documentation for your target for more info about it as well as
|
||||
SysfsRules file for more info about common to all dev handlers rules.
|
||||
SysfsRules file for more info about common to all targets rules.
|
||||
Every target should have at least the following entries:
|
||||
|
||||
- ini_group - subdirectory, which contains and allows to define
|
||||
- ini_groups - subdirectory, which contains and allows to define
|
||||
initiator-oriented access control information, see below.
|
||||
|
||||
- luns - subdirectory, which contains list of available LUNs in the
|
||||
@@ -698,6 +703,14 @@ Every target should have at least the following entries:
|
||||
until rel_tgt_id becomes unique. This attribute initialized unique by
|
||||
SCST by default.
|
||||
|
||||
A target driver may have also the follwoing entries:
|
||||
|
||||
- "hw_target" - if the target driver supports both hardware and virtual
|
||||
targets (for instance, an FC adapter supporting NPIV, which has
|
||||
hardware targets for its physical ports as well as virtual NPIV
|
||||
targets), this read only attribute for all hardware targets will
|
||||
exist and contain value 1.
|
||||
|
||||
Subdirectory "sessions" contains one subdirectory for each connected
|
||||
session with name equal to name of the connected initiator.
|
||||
|
||||
@@ -794,7 +807,7 @@ are one or more param_name=value pairs separated by ';'.
|
||||
|
||||
To configure the initiator-oriented access control SCST provides the
|
||||
following interface. Each target's sysfs subdirectory
|
||||
(/sys/kernel/scst_tgt/targets/target_driver/target_name) has "ini_group"
|
||||
(/sys/kernel/scst_tgt/targets/target_driver/target_name) has "ini_groups"
|
||||
subdirectory. This subdirectory contains the list of already defined
|
||||
security groups for this target as well as file "mgmt". This file has
|
||||
the following commands, which you can send to it, for instance, using
|
||||
@@ -838,17 +851,17 @@ subdirectory of the target-oriented access control.
|
||||
|
||||
Examples:
|
||||
|
||||
- echo "create INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/mgmt -
|
||||
- echo "create INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/mgmt -
|
||||
creates security group INI for target iqn.2006-10.net.vlnb:tgt1.
|
||||
|
||||
- echo "add 2:0:1:0 11" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI/luns/mgmt -
|
||||
- echo "add 2:0:1:0 11" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI/luns/mgmt -
|
||||
adds a pass-through device sitting on host 2, channel 0, ID 1, LUN 0
|
||||
to group with name INI as LUN 11.
|
||||
|
||||
- echo "add disk1 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI/luns/mgmt -
|
||||
- echo "add disk1 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI/luns/mgmt -
|
||||
adds a virtual disk with name disk1 to group with name INI as LUN 0.
|
||||
|
||||
- echo "add 21:*:e0:?b:83:*" >/sys/kernel/scst_tgt/targets/21:00:00:a0:8c:54:52:12/ini_group/INI/initiators/mgmt -
|
||||
- echo "add 21:*:e0:?b:83:*" >/sys/kernel/scst_tgt/targets/21:00:00:a0:8c:54:52:12/ini_groups/INI/initiators/mgmt -
|
||||
adds a pattern to group with name INI to Fibre Channel target with
|
||||
WWN 21:00:00:a0:8c:54:52:12, which matches WWNs of Fibre Channel
|
||||
initiator ports.
|
||||
@@ -864,11 +877,11 @@ do the following commands:
|
||||
# echo "iqn.2007-05.com.example:storage.disk1.sys1.xyz" >/sys/kernel/scst_tgt/targets/iscsi/mgmt
|
||||
# echo "add dev1 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/luns/mgmt
|
||||
# echo "add dev2 1" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/luns/mgmt
|
||||
# echo "create SPEC_INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_group/mgmt
|
||||
# echo "create SPEC_INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_groups/mgmt
|
||||
# echo "add dev2 0 read_only=1" \
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_group/SPEC_INI/luns/mgmt
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_groups/SPEC_INI/luns/mgmt
|
||||
# echo "iqn.2007-05.com.example:storage.disk1.spec_ini.xyz" \
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_group/SPEC_INI/initiators/mgmt
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_groups/SPEC_INI/initiators/mgmt
|
||||
|
||||
For Fibre Channel or SAS in the above example you should use target's
|
||||
and initiator ports WWNs instead of iSCSI names.
|
||||
@@ -1137,10 +1150,10 @@ For example:
|
||||
|-- blocksize
|
||||
|-- exported
|
||||
| |-- export0 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt/luns/0
|
||||
| |-- export1 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt/ini_group/INI/luns/0
|
||||
| |-- export1 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt/ini_groups/INI/luns/0
|
||||
| |-- export2 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/luns/0
|
||||
| |-- export3 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI1/luns/0
|
||||
| |-- export4 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI2/luns/0
|
||||
| |-- export3 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI1/luns/0
|
||||
| |-- export4 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI2/luns/0
|
||||
|-- filename
|
||||
|-- handler -> ../../handlers/vdisk_fileio
|
||||
|-- nv_cache
|
||||
@@ -1313,17 +1326,46 @@ Pass-through mode
|
||||
|
||||
In the pass-through mode (i.e. using the pass-through device handlers
|
||||
scst_disk, scst_tape, etc) SCSI commands, coming from remote initiators,
|
||||
are passed to local SCSI hardware on target as is, without any
|
||||
modifications. As any other hardware, the local SCSI hardware can not
|
||||
handle commands with amount of data and/or segments count in
|
||||
scatter-gather array bigger some values. Therefore, when using the
|
||||
pass-through mode you should note that values for maximum number of
|
||||
segments and maximum amount of transferred data for each SCSI command on
|
||||
devices on initiators can not be bigger, than corresponding values of
|
||||
the corresponding SCSI devices on the target. Otherwise you will see
|
||||
symptoms like small transfers work well, but large ones stall and
|
||||
messages like: "Unable to complete command due to SG IO count
|
||||
limitation" are printed in the kernel logs.
|
||||
are passed to local SCSI devices on target as is, without any
|
||||
modifications.
|
||||
|
||||
In the SYSFS interface all real SCSI devices are listed in
|
||||
/sys/kernel/scst_tgt/devices in form host:channel:id:lun numbers, for
|
||||
instance 1:0:0:0. The recommended way to match those numbers to your
|
||||
devices is use of lsscsi utility.
|
||||
|
||||
When a pass-through dev handler is loaded it assigns itself to all
|
||||
existing SCSI devices of its SCSI type. If you later want to unassign some
|
||||
SCSI device from it or assign it to another dev handler you can use the
|
||||
following interface.
|
||||
|
||||
Each pass-through dev handler has in its root subdirectory
|
||||
/sys/kernel/scst_tgt/handlers/handler_name, e.g.
|
||||
/sys/kernel/scst_tgt/handlers/dev_disk, "mgmt" file. It allows the
|
||||
following commands. They can be sent to it using, e.g., echo command.
|
||||
|
||||
- "assign" - this command assigns SCSI device with
|
||||
host:channel:id:lun numbers to this dev handler.
|
||||
|
||||
echo "assign 1:0:0:0" >mgmt
|
||||
|
||||
will assign SCSI device 1:0:0:0 to this dev handler.
|
||||
|
||||
- "unassign" - this command unassigns SCSI device with
|
||||
host:channel:id:lun numbers from this dev handler.
|
||||
|
||||
As usually, on read the "mgmt" file returns small help about available
|
||||
commands.
|
||||
|
||||
As any other hardware, the local SCSI hardware can not handle commands
|
||||
with amount of data and/or segments count in scatter-gather array bigger
|
||||
some values. Therefore, when using the pass-through mode you should note
|
||||
that values for maximum number of segments and maximum amount of
|
||||
transferred data for each SCSI command on devices on initiators can not
|
||||
be bigger, than corresponding values of the corresponding SCSI devices
|
||||
on the target. Otherwise you will see symptoms like small transfers work
|
||||
well, but large ones stall and messages like: "Unable to complete
|
||||
command due to SG IO count limitation" are printed in the kernel logs.
|
||||
|
||||
You can't control from the user space limit of the scatter-gather
|
||||
segments, but for block devices usually it is sufficient if you set on
|
||||
|
||||
+66
-24
@@ -571,6 +571,11 @@ documentation for your dev handlers for more info about it as well as
|
||||
SysfsRules file for more info about common to all dev handlers rules.
|
||||
Standard SCST dev handlers have at least the following common entries:
|
||||
|
||||
- mgmt - this entry allows to create virtual devices and their
|
||||
attributes (for virtual devices dev handlers) or assign/unassign real
|
||||
SCSI devices to/from this dev handler (for pass-through dev
|
||||
handlers).
|
||||
|
||||
- pass_through - if exists, it contains 1 and this dev handler is a
|
||||
pass-through dev handler.
|
||||
|
||||
@@ -597,10 +602,10 @@ Each SGV cache's subdirectory has the following item:
|
||||
|
||||
Content of each target's subdirectory is target specific. See
|
||||
documentation for your target for more info about it as well as
|
||||
SysfsRules file for more info about common to all dev handlers rules.
|
||||
SysfsRules file for more info about common to all targets rules.
|
||||
Every target should have at least the following entries:
|
||||
|
||||
- ini_group - subdirectory, which contains and allows to define
|
||||
- ini_groups - subdirectory, which contains and allows to define
|
||||
initiator-oriented access control information, see below.
|
||||
|
||||
- luns - subdirectory, which contains list of available LUNs in the
|
||||
@@ -621,6 +626,14 @@ Every target should have at least the following entries:
|
||||
until rel_tgt_id becomes unique. This attribute initialized unique by
|
||||
SCST by default.
|
||||
|
||||
A target driver may have also the follwoing entries:
|
||||
|
||||
- "hw_target" - if the target driver supports both hardware and virtual
|
||||
targets (for instance, an FC adapter supporting NPIV, which has
|
||||
hardware targets for its physical ports as well as virtual NPIV
|
||||
targets), this read only attribute for all hardware targets will
|
||||
exist and contain value 1.
|
||||
|
||||
Subdirectory "sessions" contains one subdirectory for each connected
|
||||
session with name equal to name of the connected initiator.
|
||||
|
||||
@@ -717,7 +730,7 @@ are one or more param_name=value pairs separated by ';'.
|
||||
|
||||
To configure the initiator-oriented access control SCST provides the
|
||||
following interface. Each target's sysfs subdirectory
|
||||
(/sys/kernel/scst_tgt/targets/target_driver/target_name) has "ini_group"
|
||||
(/sys/kernel/scst_tgt/targets/target_driver/target_name) has "ini_groups"
|
||||
subdirectory. This subdirectory contains the list of already defined
|
||||
security groups for this target as well as file "mgmt". This file has
|
||||
the following commands, which you can send to it, for instance, using
|
||||
@@ -761,17 +774,17 @@ subdirectory of the target-oriented access control.
|
||||
|
||||
Examples:
|
||||
|
||||
- echo "create INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/mgmt -
|
||||
- echo "create INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/mgmt -
|
||||
creates security group INI for target iqn.2006-10.net.vlnb:tgt1.
|
||||
|
||||
- echo "add 2:0:1:0 11" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI/luns/mgmt -
|
||||
- echo "add 2:0:1:0 11" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI/luns/mgmt -
|
||||
adds a pass-through device sitting on host 2, channel 0, ID 1, LUN 0
|
||||
to group with name INI as LUN 11.
|
||||
|
||||
- echo "add disk1 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI/luns/mgmt -
|
||||
- echo "add disk1 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI/luns/mgmt -
|
||||
adds a virtual disk with name disk1 to group with name INI as LUN 0.
|
||||
|
||||
- echo "add 21:*:e0:?b:83:*" >/sys/kernel/scst_tgt/targets/21:00:00:a0:8c:54:52:12/ini_group/INI/initiators/mgmt -
|
||||
- echo "add 21:*:e0:?b:83:*" >/sys/kernel/scst_tgt/targets/21:00:00:a0:8c:54:52:12/ini_groups/INI/initiators/mgmt -
|
||||
adds a pattern to group with name INI to Fibre Channel target with
|
||||
WWN 21:00:00:a0:8c:54:52:12, which matches WWNs of Fibre Channel
|
||||
initiator ports.
|
||||
@@ -787,11 +800,11 @@ do the following commands:
|
||||
# echo "iqn.2007-05.com.example:storage.disk1.sys1.xyz" >/sys/kernel/scst_tgt/targets/iscsi/mgmt
|
||||
# echo "add dev1 0" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/luns/mgmt
|
||||
# echo "add dev2 1" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/luns/mgmt
|
||||
# echo "create SPEC_INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_group/mgmt
|
||||
# echo "create SPEC_INI" >/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_groups/mgmt
|
||||
# echo "add dev2 0 read_only=1" \
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_group/SPEC_INI/luns/mgmt
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_groups/SPEC_INI/luns/mgmt
|
||||
# echo "iqn.2007-05.com.example:storage.disk1.spec_ini.xyz" \
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_group/SPEC_INI/initiators/mgmt
|
||||
>/sys/kernel/scst_tgt/targets/iscsi/iqn.2007-05.com.example:storage.disk1.sys1.xyz/ini_groups/SPEC_INI/initiators/mgmt
|
||||
|
||||
For Fibre Channel or SAS in the above example you should use target's
|
||||
and initiator ports WWNs instead of iSCSI names.
|
||||
@@ -1061,10 +1074,10 @@ For example:
|
||||
|-- blocksize
|
||||
|-- exported
|
||||
| |-- export0 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt/luns/0
|
||||
| |-- export1 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt/ini_group/INI/luns/0
|
||||
| |-- export1 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt/ini_groups/INI/luns/0
|
||||
| |-- export2 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/luns/0
|
||||
| |-- export3 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI1/luns/0
|
||||
| |-- export4 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_group/INI2/luns/0
|
||||
| |-- export3 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI1/luns/0
|
||||
| |-- export4 -> ../../../targets/iscsi/iqn.2006-10.net.vlnb:tgt1/ini_groups/INI2/luns/0
|
||||
|-- filename
|
||||
|-- handler -> ../../handlers/vdisk_fileio
|
||||
|-- nv_cache
|
||||
@@ -1237,18 +1250,47 @@ Pass-through mode
|
||||
|
||||
In the pass-through mode (i.e. using the pass-through device handlers
|
||||
scst_disk, scst_tape, etc) SCSI commands, coming from remote initiators,
|
||||
are passed to local SCSI hardware on target as is, without any
|
||||
modifications. As any other hardware, the local SCSI hardware can not
|
||||
handle commands with amount of data and/or segments count in
|
||||
scatter-gather array bigger some values. Therefore, when using the
|
||||
pass-through mode you should note that values for maximum number of
|
||||
segments and maximum amount of transferred data for each SCSI command on
|
||||
devices on initiators can not be bigger, than corresponding values of
|
||||
the corresponding SCSI devices on the target. Otherwise you will see
|
||||
symptoms like small transfers work well, but large ones stall and
|
||||
messages like: "Unable to complete command due to SG IO count
|
||||
limitation" are printed in the kernel logs.
|
||||
are passed to local SCSI devices on target as is, without any
|
||||
modifications.
|
||||
|
||||
In the SYSFS interface all real SCSI devices are listed in
|
||||
/sys/kernel/scst_tgt/devices in form host:channel:id:lun numbers, for
|
||||
instance 1:0:0:0. The recommended way to match those numbers to your
|
||||
devices is use of lsscsi utility.
|
||||
|
||||
When a pass-through dev handler is loaded it assigns itself to all
|
||||
existing SCSI devices of its SCSI type. If you later want to unassign some
|
||||
SCSI device from it or assign it to another dev handler you can use the
|
||||
following interface.
|
||||
|
||||
Each pass-through dev handler has in its root subdirectory
|
||||
/sys/kernel/scst_tgt/handlers/handler_name, e.g.
|
||||
/sys/kernel/scst_tgt/handlers/dev_disk, "mgmt" file. It allows the
|
||||
following commands. They can be sent to it using, e.g., echo command.
|
||||
|
||||
- "assign" - this command assigns SCSI device with
|
||||
host:channel:id:lun numbers to this dev handler.
|
||||
|
||||
echo "assign 1:0:0:0" >mgmt
|
||||
|
||||
will assign SCSI device 1:0:0:0 to this dev handler.
|
||||
|
||||
- "unassign" - this command unassigns SCSI device with
|
||||
host:channel:id:lun numbers from this dev handler.
|
||||
|
||||
As usually, on read the "mgmt" file returns small help about available
|
||||
commands.
|
||||
|
||||
As any other hardware, the local SCSI hardware can not handle commands
|
||||
with amount of data and/or segments count in scatter-gather array bigger
|
||||
some values. Therefore, when using the pass-through mode you should note
|
||||
that values for maximum number of segments and maximum amount of
|
||||
transferred data for each SCSI command on devices on initiators can not
|
||||
be bigger, than corresponding values of the corresponding SCSI devices
|
||||
on the target. Otherwise you will see symptoms like small transfers work
|
||||
well, but large ones stall and messages like: "Unable to complete
|
||||
command due to SG IO count limitation" are printed in the kernel logs.
|
||||
|
||||
You can't control from the user space limit of the scatter-gather
|
||||
segments, but for block devices usually it is sufficient if you set on
|
||||
the initiators /sys/block/DEVICE_NAME/queue/max_sectors_kb in the same
|
||||
|
||||
+801
@@ -0,0 +1,801 @@
|
||||
SCST SYSFS interface rules
|
||||
==========================
|
||||
|
||||
This file describes SYSFS interface rules, which all SCST target
|
||||
drivers, dev handlers and management utilities MUST follow. This allows
|
||||
to have a simple, self-documented, target drivers and dev handlers
|
||||
independent management interface.
|
||||
|
||||
Words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119.
|
||||
|
||||
In this document "key attribute" means a configuration attribute with
|
||||
not default value, which must be configured during the target driver's
|
||||
initialization. A key attribute MUST have in the last line keyword
|
||||
"[key]". If a default value set to a key attribute, it becomes a regular
|
||||
none-key attribute. For instance, iSCSI target has attribute DataDigest.
|
||||
Default value for this attribute is "None". It value "CRC32C" is set to
|
||||
this attribute, it will become a key attribute. If value "None" is again
|
||||
set, this attribute will become back to a none-key attribute.
|
||||
|
||||
Each user configurable attribute with a not default value MUST be marked
|
||||
as key attribute.
|
||||
|
||||
|
||||
I. Rules for target drivers
|
||||
===========================
|
||||
|
||||
SCST core for each target driver (struct scst_tgt_template) creates a
|
||||
root subdirectory in /sys/kernel/scst_tgt/targets with name
|
||||
scst_tgt_template.name (called "target_driver_name" further in this
|
||||
document).
|
||||
|
||||
For each target (struct scst_tgt) SCST core creates a root subdirectory
|
||||
in /sys/kernel/scst_tgt/targets/target_driver_name with name
|
||||
scst_tgt.tgt_name (called "target_name" further in this document).
|
||||
|
||||
There are 2 type of targets possible: hardware and virtual targets.
|
||||
Hardware targets are targets corresponding to real hardware, for
|
||||
instance, a Fibre Channel adapter's port. Virtual targets are hardware
|
||||
independent targets, which can be dynamically added or removed, for
|
||||
instance, an iSCSI target, or NPIV Fibre Channel target.
|
||||
|
||||
A target driver supporting virtual targets must support "mgmt" attribute
|
||||
and "add_target"/"del_target" commands.
|
||||
|
||||
If target driver supports both hardware and virtual targets (for
|
||||
instance, an FC adapter supporting NPIV, which has hardware targets for
|
||||
its physical ports as well as virtual NPIV targets), it MUST create each
|
||||
hardware target with hw_target mark to make SCST core create "hw_target"
|
||||
attribute (see below).
|
||||
|
||||
Attributes for target drivers
|
||||
-----------------------------
|
||||
|
||||
A target driver MAY support in its root subdirectory the following
|
||||
optional attributes. Target drivers MAY also support there other
|
||||
read-only or read-writable attributes.
|
||||
|
||||
1. "enabled" - this attribute MUST allow to enable and disable target
|
||||
driver as a whole, i.e. if disabled, the target driver MUST NOT accept
|
||||
new connections. The goal of this attribute is to allow the target
|
||||
driver's initial configuration. For instance, iSCSI target may need to
|
||||
have discovery user names and passwords set before it starts serving
|
||||
discovery connections.
|
||||
|
||||
This attribute MUST have read and write permissions for superuser and be
|
||||
read-only for other users.
|
||||
|
||||
On read it MUST return 0, if the target driver is disabled, and 1, if it
|
||||
is enabled.
|
||||
|
||||
On write it MUST accept '0' character as request to disable and '1' as
|
||||
request to enable, but MAY also accept other driver specific commands.
|
||||
|
||||
During disabling the target driver MAY close already connected sessions
|
||||
in all targets, but this is OPTIONAL.
|
||||
|
||||
MUST be 0 by default.
|
||||
|
||||
2. "trace_level" - this attribute SHOULD allow to change log level of this
|
||||
driver.
|
||||
|
||||
This attribute SHOULD have read and write permissions for superuser and be
|
||||
read-only for other users.
|
||||
|
||||
On read it SHOULD return a help text about available command and log levels.
|
||||
|
||||
On write it SHOULD accept commands to change log levels according to the
|
||||
help text.
|
||||
|
||||
For example:
|
||||
|
||||
out_of_mem | minor | pid | line | function | special | mgmt | mgmt_dbg | flow_control | conn
|
||||
|
||||
Usage:
|
||||
echo "all|none|default" >trace_level
|
||||
echo "value DEC|0xHEX|0OCT" >trace_level
|
||||
echo "add|del TOKEN" >trace_level
|
||||
|
||||
where TOKEN is one of [debug, function, line, pid,
|
||||
entryexit, buff, mem, sg, out_of_mem,
|
||||
special, scsi, mgmt, minor,
|
||||
mgmt_dbg, scsi_serializing,
|
||||
retry, recv_bot, send_bot, recv_top,
|
||||
send_top, d_read, d_write, conn, conn_dbg, iov, pdu, net_page]
|
||||
|
||||
|
||||
3. "version" - this read-only for all attribute SHOULD return version of
|
||||
the target driver and some info about its enabled compile time facilities.
|
||||
|
||||
For example:
|
||||
|
||||
2.0.0
|
||||
EXTRACHECKS
|
||||
DEBUG
|
||||
|
||||
4. "mgmt" - this attribute MUST allow to add and delete targets, if
|
||||
virtual targets are supported by this driver, as well as it MAY allow to
|
||||
add and delete the target driver's or its targets' attributes.
|
||||
|
||||
This attribute MUST have read and write permissions for superuser and be
|
||||
read-only for other users.
|
||||
|
||||
On read it MUST return a help string describing available commands and
|
||||
parameters.
|
||||
|
||||
For example:
|
||||
|
||||
Usage: echo "add_target target_name [parameters]" >mgmt
|
||||
echo "del_target target_name" >mgmt
|
||||
echo "add_attribute IncomingUser name password" >mgmt
|
||||
echo "del_attribute IncomingUser name" >mgmt
|
||||
echo "add_attribute OutgoingUser name password" >mgmt
|
||||
echo "del_attribute OutgoingUser name" >mgmt
|
||||
echo "add_target_attribute target_name IncomingUser name password" >mgmt
|
||||
echo "del_target_attribute target_name IncomingUser name" >mgmt
|
||||
echo "add_target_attribute target_name OutgoingUser name password" >mgmt
|
||||
echo "del_target_attribute target_name OutgoingUser name" >mgmt
|
||||
|
||||
where parameters are one or more param_name=value pairs separated by ';'
|
||||
|
||||
4.1. "add_target" - if supported, this command MUST add new target with
|
||||
name "target_name" and specified optional or required parameters. Each
|
||||
parameter MUST be in form "parameter=value". All parameters MUST be
|
||||
separated by ';' symbol.
|
||||
|
||||
All target drivers supporting creation of virtual targets MUST support
|
||||
this command.
|
||||
|
||||
All target drivers supporting "add_target" command MUST support all
|
||||
read-only targets' key attributes as parameters to "add_target" command
|
||||
with the attributes' names as parameters' names and the attributes'
|
||||
values as parameters' values.
|
||||
|
||||
For example:
|
||||
|
||||
echo "add_target TARGET1 parameter1=1; parameter2=2" >mgmt
|
||||
|
||||
will add target with name "TARGET1" and parameters with names
|
||||
"parameter1" and "parameter2" with values 1 and 2 correspondingly.
|
||||
|
||||
4.2. "del_target" - if supported, this command MUST delete target with
|
||||
name "target_name". If "add_target" command is supported "del_target"
|
||||
MUST also be supported.
|
||||
|
||||
4.3. "add_attribute" - if supported, this command MUST add a target
|
||||
driver's attribute with the specified name and one or more values.
|
||||
|
||||
All target drivers supporting run time creation of the target driver's
|
||||
key attributes MUST support this command.
|
||||
|
||||
For example, for iSCSI target:
|
||||
|
||||
echo "add_attribute IncomingUser name password" >mgmt
|
||||
|
||||
will add for discovery sessions an incoming user (attribute
|
||||
/sys/kernel/scst_tgt/targets/iscsi/IncomingUser) with name "name" and
|
||||
password "password".
|
||||
|
||||
4.4. "del_attribute" - if supported, this command MUST delete target
|
||||
driver's attribute with the specified name and values. The values MUST
|
||||
be specified, because in some cases attributes MAY internally be
|
||||
distinguished by values. For instance, iSCSI target might have several
|
||||
incoming users. If not needed, target driver might ignore the values.
|
||||
|
||||
If "add_attribute" command is supported "del_attribute" MUST
|
||||
also be supported.
|
||||
|
||||
4.5. "add_target_attribute" - if supported, this command MUST add new
|
||||
attribute for the specified target with the specified name and one or
|
||||
more values.
|
||||
|
||||
All target drivers supporting run time creation of targets' key
|
||||
attributes MUST support this command.
|
||||
|
||||
For example:
|
||||
|
||||
echo "add_target_attribute iqn.2006-10.net.vlnb:tgt IncomingUser name password" >mgmt
|
||||
|
||||
will add for target with name "iqn.2006-10.net.vlnb:tgt" an incoming
|
||||
user (attribute
|
||||
/sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt/IncomingUser)
|
||||
with name "name" and password "password".
|
||||
|
||||
4.6. "del_target_attribute" - if supported, this command MUST delete
|
||||
target's attribute with the specified name and values. The values MUST
|
||||
be specified, because in some cases attributes MAY internally be
|
||||
distinguished by values. For instance, iSCSI target might have several
|
||||
incoming users. If not needed, target driver might ignore the values.
|
||||
|
||||
If "add_target_attribute" command is supported "del_target_attribute"
|
||||
MUST also be supported.
|
||||
|
||||
Attributes for targets
|
||||
----------------------
|
||||
|
||||
Each target MAY support in its root subdirectory the following optional
|
||||
attributes. Target drivers MAY also support there other read-only or
|
||||
read-writable attributes.
|
||||
|
||||
1. "enabled" - this attribute MUST allow to enable and disable the
|
||||
corresponding target, i.e. if disabled, the target MUST NOT accept new
|
||||
connections. The goal of this attribute is to allow the target's initial
|
||||
configuration. For instance, each target needs to have its LUNs setup
|
||||
before it starts serving initiators. Another example is iSCSI target,
|
||||
which may need to have initialized a number of iSCSI parameters before
|
||||
it starts accepting new iSCSI connections.
|
||||
|
||||
This attribute MUST have read and write permissions for superuser and be
|
||||
read-only for other users.
|
||||
|
||||
On read it MUST return 0, if the target is disabled, and 1, if it is
|
||||
enabled.
|
||||
|
||||
On write it MUST accept '0' character as request to disable and '1' as
|
||||
request to enable. Other requests MUST be rejected.
|
||||
|
||||
SCST core provides some facilities, which MUST be used to implement this
|
||||
attribute.
|
||||
|
||||
During disabling the target driver MAY close already connected sessions
|
||||
to the target, but this is OPTIONAL.
|
||||
|
||||
MUST be 0 by default.
|
||||
|
||||
SCST core will automatically create for all targets the following
|
||||
attributes:
|
||||
|
||||
1. "rel_tgt_id" - allows to read or write SCSI Relative Target Port
|
||||
Identifier attribute.
|
||||
|
||||
2. "hw_target" - allows to distinguish hardware and virtual targets, if
|
||||
the target driver supports both.
|
||||
|
||||
To provide OPTIONAL force close session functionality target drivers
|
||||
MUST implement it using "force_close" write only session's attribute,
|
||||
which on write to it MUST close the corresponding session.
|
||||
|
||||
See SCST core's README for more info about those attributes.
|
||||
|
||||
II. Rules for dev handlers
|
||||
==========================
|
||||
|
||||
There are 2 types of dev handlers: parent dev handlers and children dev
|
||||
handlers. The children dev handlers depend from the parent dev handlers.
|
||||
|
||||
SCST core for each parent dev handler (struct scst_dev_type with
|
||||
parent member with value NULL) creates a root subdirectory in
|
||||
/sys/kernel/scst_tgt/handlers with name scst_dev_type.name (called
|
||||
"dev_handler_name" further in this document).
|
||||
|
||||
Parent dev handlers can have one or more subdirectories for children dev
|
||||
handlers with names scst_dev_type.name of them.
|
||||
|
||||
Only one level of the dev handlers' parent/children hierarchy is
|
||||
allowed. Parent dev handlers, which support children dev handlers, MUST
|
||||
NOT handle devices and MUST be only placeholders for the children dev
|
||||
handlers.
|
||||
|
||||
Further in this document children dev handlers or parent dev handlers,
|
||||
which don't support children, will be called "end level dev handlers".
|
||||
|
||||
Each end level dev handler MUST be either for pass-through, or for
|
||||
virtual devices.
|
||||
|
||||
End level dev handlers can be recognized by existence of the "mgmt"
|
||||
attribute.
|
||||
|
||||
For each device (struct scst_device) SCST core creates a root
|
||||
subdirectory in /sys/kernel/scst_tgt/devices/device_name with name
|
||||
scst_device.virt_name (called "device_name" further in this document).
|
||||
|
||||
Attributes for dev handlers
|
||||
---------------------------
|
||||
|
||||
Each pass-through dev handler MUST have in its root subdirectory
|
||||
"pass-through" and "mgmt" attributes and the "mgmt" attribute MUST
|
||||
support "assign" and "unassign" commands as described below.
|
||||
|
||||
Each virtual devices dev handler MUST have it in its root subdirectory
|
||||
"mgmt" attribute, which MUST support "add_device" and "del_device"
|
||||
attributes as described below.
|
||||
|
||||
Parent dev handlers and end level dev handlers without parents MAY
|
||||
support in its root subdirectory the following optional attributes. They
|
||||
MAY also support there other read-only or read-writable attributes.
|
||||
|
||||
1. "trace_level" - this attribute SHOULD allow to change log level of this
|
||||
driver.
|
||||
|
||||
This attribute SHOULD have read and write permissions for superuser and be
|
||||
read-only for other users.
|
||||
|
||||
On read it SHOULD return a help text about available command and log levels.
|
||||
|
||||
On write it SHOULD accept commands to change log levels according to the
|
||||
help text.
|
||||
|
||||
For example:
|
||||
|
||||
out_of_mem | minor | pid | line | function | special | mgmt | mgmt_dbg
|
||||
|
||||
|
||||
Usage:
|
||||
echo "all|none|default" >trace_level
|
||||
echo "value DEC|0xHEX|0OCT" >trace_level
|
||||
echo "add|del TOKEN" >trace_level
|
||||
|
||||
where TOKEN is one of [debug, function, line, pid,
|
||||
entryexit, buff, mem, sg, out_of_mem,
|
||||
special, scsi, mgmt, minor,
|
||||
mgmt_dbg, scsi_serializing,
|
||||
retry, recv_bot, send_bot, recv_top,
|
||||
send_top]
|
||||
|
||||
2. "version" - this read-only for all attribute SHOULD return version of
|
||||
the dev handler and some info about its enabled compile time facilities.
|
||||
|
||||
For example:
|
||||
|
||||
2.0.0
|
||||
EXTRACHECKS
|
||||
DEBUG
|
||||
|
||||
End level dev handlers in their root subdirectories MUST support "mgmt"
|
||||
attribute and MAY support other read-only or read-writable attributes.
|
||||
This attribute MUST have read and write permissions for superuser and be
|
||||
read-only for other users.
|
||||
|
||||
Attribute "mgmt" for virtual devices dev handlers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For virtual devices dev handlers "mgmt" attribute MUST allow to add and
|
||||
delete devices as well as it MAY allow to add and delete the dev
|
||||
handler's or its devices' attributes.
|
||||
|
||||
On read it MUST return a help string describing available commands and
|
||||
parameters.
|
||||
|
||||
For example:
|
||||
|
||||
Usage: echo "add_device device_name [parameters]" >mgmt
|
||||
echo "del_device device_name" >mgmt
|
||||
echo "add_attribute AttributeX ValueX" >mgmt
|
||||
echo "del_attribute AttributeX ValueX" >mgmt
|
||||
echo "add_attribute AttributeY ValueY1 ValueY2" >mgmt
|
||||
echo "del_attribute AttributeY" >mgmt
|
||||
echo "add_device_attribute device_name AttributeDX ValueDX" >mgmt
|
||||
echo "del_device_attribute device_name AttributeDX ValueDX" >mgmt
|
||||
echo "add_device_attribute device_name AttributeDY ValueY1 ValueY2" >mgmt
|
||||
echo "del_device_attribute device_name AttributeDY" >mgmt
|
||||
|
||||
where parameters are one or more param_name=value pairs separated by ';'
|
||||
|
||||
The following parameters available: filename, blocksize, write_through, nv_cache, o_direct, read_only, removable
|
||||
|
||||
1. "add_device" - this command MUST add new device with name
|
||||
"device_name" and specified optional or required parameters. Each
|
||||
parameter MUST be in form "parameter=value". All parameters MUST be
|
||||
separated by ';' symbol.
|
||||
|
||||
All dev handlers supporting "add_device" command MUST support all
|
||||
read-only devices' key attributes as parameters to "add_device" command
|
||||
with the attributes' names as parameters' names and the attributes'
|
||||
values as parameters' values.
|
||||
|
||||
For example:
|
||||
|
||||
echo "add_device device1 parameter1=1; parameter2=2" >mgmt
|
||||
|
||||
will add device with name "device1" and parameters with names
|
||||
"parameter1" and "parameter2" with values 1 and 2 correspondingly.
|
||||
|
||||
2. "del_device" - this command MUST delete device with name
|
||||
"device_name".
|
||||
|
||||
3. "add_attribute" - if supported, this command MUST add a device
|
||||
driver's attribute with the specified name and one or more values.
|
||||
|
||||
All dev handlers supporting run time creation of the dev handler's
|
||||
key attributes MUST support this command.
|
||||
|
||||
For example:
|
||||
|
||||
echo "add_attribute AttributeX ValueX" >mgmt
|
||||
|
||||
will add attribute
|
||||
/sys/kernel/scst_tgt/handlers/dev_handler_name/AttributeX with value ValueX.
|
||||
|
||||
4. "del_attribute" - if supported, this command MUST delete device
|
||||
driver's attribute with the specified name and values. The values MUST
|
||||
be specified, because in some cases attributes MAY internally be
|
||||
distinguished by values. If not needed, dev handler might ignore the
|
||||
values.
|
||||
|
||||
If "add_attribute" command is supported "del_attribute" MUST also be
|
||||
supported.
|
||||
|
||||
5. "add_device_attribute" - if supported, this command MUST add new
|
||||
attribute for the specified device with the specified name and one or
|
||||
more values.
|
||||
|
||||
All dev handlers supporting run time creation of devices' key attributes
|
||||
MUST support this command.
|
||||
|
||||
For example:
|
||||
|
||||
echo "add_device_attribute device1 AttributeDX ValueDX" >mgmt
|
||||
|
||||
will add for device with name "device1" attribute
|
||||
/sys/kernel/scst_tgt/devices/device_name/AttributeDX) with value
|
||||
ValueDX.
|
||||
|
||||
6. "del_device_attribute" - if supported, this command MUST delete
|
||||
device's attribute with the specified name and values. The values MUST
|
||||
be specified, because in some cases attributes MAY internally be
|
||||
distinguished by values. If not needed, dev handler might ignore the
|
||||
values.
|
||||
|
||||
If "add_device_attribute" command is supported "del_device_attribute"
|
||||
MUST also be supported.
|
||||
|
||||
Attribute "mgmt" for pass-through devices dev handlers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For pass-through devices dev handlers "mgmt" attribute MUST allow to
|
||||
assign and unassign this dev handler to existing SCSI devices.
|
||||
|
||||
On read it MUST return a help string describing available commands and
|
||||
parameters.
|
||||
|
||||
For example:
|
||||
|
||||
Usage: echo "assign H:C:I:L" >mgmt
|
||||
echo "unassign H:C:I:L" >mgmt
|
||||
|
||||
1. "assign" - this command MUST assign SCSI device with
|
||||
host:channel:id:lun numbers to this dev handler.
|
||||
|
||||
All pass-through dev handlers MUST support this command.
|
||||
|
||||
For example:
|
||||
|
||||
echo "assign 1:0:0:0" >mgmt
|
||||
|
||||
will assign SCSI device 1:0:0:0 to this dev handler.
|
||||
|
||||
2. "unassign" - this command MUST unassign SCSI device with
|
||||
host:channel:id:lun numbers from this dev handler.
|
||||
|
||||
SCST core will automatically create for all dev handlers the following
|
||||
attributes:
|
||||
|
||||
1. "pass_through" - if the dev handler is a handler for pass-through
|
||||
devices, SCST core create this attribute. This attribute will have value
|
||||
1.
|
||||
|
||||
2. "type" - SCSI type of device this dev handler can handle.
|
||||
|
||||
See SCST core's README for more info about those attributes.
|
||||
|
||||
Attributes for devices
|
||||
----------------------
|
||||
|
||||
Each device MAY support in its root subdirectory any read-only or
|
||||
read-writable attributes.
|
||||
|
||||
SCST core will automatically create for all devices the following
|
||||
attributes:
|
||||
|
||||
1. "type" - SCSI type of this device
|
||||
|
||||
See SCST core's README for more info about those attributes.
|
||||
|
||||
|
||||
III. Rules for management utilities
|
||||
===================================
|
||||
|
||||
Rules summary
|
||||
-------------
|
||||
|
||||
A management utility (scstadmin) SHOULD NOT keep any knowledge specific
|
||||
to any device, dev handler, target or target driver. It SHOULD only know
|
||||
the common SCST SYSFS rules, which all dev handlers target drivers MUST
|
||||
follow. Namely:
|
||||
|
||||
Common rules:
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
1. All key attributes MUST be marked by mark "[key]" in the last line of
|
||||
the attribute.
|
||||
|
||||
2. All not key attributes don't matter and SHOULD be ignored.
|
||||
|
||||
For target drivers and targets:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
1. If target driver supports adding new targets, it MUST have "mgmt"
|
||||
attribute, which MUST support "add_target" and "del_target" commands as
|
||||
specified above.
|
||||
|
||||
2. If target driver supports run time adding new key attributes, it MUST
|
||||
have "mgmt" attribute, which MUST support "add_attribute" and
|
||||
"del_attribute" commands as specified above.
|
||||
|
||||
3. If target driver supports both hardware and virtual targets, all its
|
||||
hardware targets MUST have "hw_target" attribute with value 1.
|
||||
|
||||
4. If target has read-only key attributes, the add_target command MUST
|
||||
support them as parameters.
|
||||
|
||||
5. If target supports run time adding new key attributes, the target
|
||||
driver MUST have "mgmt" attribute, which MUST support
|
||||
"add_target_attribute" and "del_target_attribute" commands as specified
|
||||
above.
|
||||
|
||||
6. Both target drivers and targets MAY support "enable" attribute. If
|
||||
supported, after configuring the corresponding target driver or target
|
||||
"1" MUST be written to this attribute in the following order: at first,
|
||||
for all targets of the target driver, then for the target driver.
|
||||
|
||||
For devices and dev handlers:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
1. Each dev handler in its root subdirectory MUST have "mgmt" attribute.
|
||||
|
||||
2. All pass-through dev handlers MUST have "pass_through" attribute.
|
||||
|
||||
3. Each virtual devices dev handler MUST support "add_device" and
|
||||
"del_device" commands to the "mgmt" attribute as specified above.
|
||||
|
||||
4. Each pass-through dev handler MUST support "assign" and "unassign"
|
||||
commands to the "mgmt" attribute as specified above.
|
||||
|
||||
5. If dev handler driver supports run time adding new key attributes, it
|
||||
MUST support "add_attribute" and "del_attribute" commands to the "mgmt"
|
||||
attribute as specified above.
|
||||
|
||||
6. All device handlers have links in the root subdirectory pointing to
|
||||
their devices.
|
||||
|
||||
7. If device has read-only key attributes, the "add_device" command MUST
|
||||
support them as parameters.
|
||||
|
||||
8. If device supports run time adding new key attributes, its dev
|
||||
handler MUST support "add_device_attribute" and "del_device_attribute"
|
||||
commands to the "mgmt" attribute as specified above.
|
||||
|
||||
9. Each device has "handler" link to its dev handler's root
|
||||
subdirectory.
|
||||
|
||||
Algorithm to convert current SCST configuration to config file
|
||||
--------------------------------------------------------------
|
||||
|
||||
A management utility SHOULD use the following algorithm when converting
|
||||
current SCST configuration to a config file:
|
||||
|
||||
1. Scan all attributes in /sys/kernel/scst_tgt (not requirsive) and store
|
||||
all found key attributes.
|
||||
|
||||
2. Scan all subdirectories of /sys/kernel/scst_tgt/handlers. Each
|
||||
subdirectory with "mgmt" attribute is a root subdirectory of a dev
|
||||
handler with name the name of the subdirectory. For each found dev
|
||||
handler do the following:
|
||||
|
||||
2.1. Store the dev handler's name. Store also its path to the root
|
||||
subdirectory, if it isn't default (/sys/kernel/scst_tgt/handlers/handler_name).
|
||||
|
||||
2.2. Store all dev handler's key attributes.
|
||||
|
||||
2.3. Go through all links in the root subdirectory pointing to
|
||||
/sys/kernel/scst_tgt/devices and for each device:
|
||||
|
||||
2.3.1. For virtual devices dev handlers:
|
||||
|
||||
2.3.1.1. Store the name of the device.
|
||||
|
||||
2.3.1.2. Store all key attributes. Mark all read only key attributes
|
||||
during storing, they will be parameters for the device's creation.
|
||||
|
||||
2.3.2. For pass-through devices dev handlers:
|
||||
|
||||
2.3.2.1. Store the H:C:I:L name of the device. Optionally, instead of
|
||||
the name unique T10 vendor device ID found using command:
|
||||
|
||||
sg_inq -p 0x83 /dev/sdX
|
||||
|
||||
can be stored. It will allow to reliably find out this device if on the
|
||||
next reboot it will have another host:channel:id:lin numbers. The sdX
|
||||
device can be found as the last letters after ':' in
|
||||
/sys/kernel/scst_tgt/devices/H:C:I:L/scsi_device/device/block:sdX.
|
||||
|
||||
3. Go through all subdirectories in /sys/kernel/scst_tgt/targets. For
|
||||
each target driver:
|
||||
|
||||
3.1. Store the name of the target driver.
|
||||
|
||||
3.2. Store all its key attributes.
|
||||
|
||||
3.3. Go through all target's subdirectories. For each target:
|
||||
|
||||
3.3.1. Store the name of the target.
|
||||
|
||||
3.3.2. Mark if the target is hardware or virtual target. The target is a
|
||||
hardware target if it has "hw_target" attribute or its target driver
|
||||
doesn't have "mgmt" attribute.
|
||||
|
||||
3.3.3. Store all key attributes. Mark all read only key attributes
|
||||
during storing, they will be parameters for the target's creation.
|
||||
|
||||
3.3.4. Scan all "luns" subdirectory and store:
|
||||
|
||||
- LUN.
|
||||
|
||||
- LU's device name.
|
||||
|
||||
- Key attributes.
|
||||
|
||||
3.3.5. Scan all "ini_groups" subdirectories. For each group store the following:
|
||||
|
||||
- The group's name.
|
||||
|
||||
- The group's LUNs (the same info as for 3.3.4).
|
||||
|
||||
- The group's initiators.
|
||||
|
||||
3.3.6. Store value of "enabled" attribute, if it exists.
|
||||
|
||||
3.4. Store value of "enabled" attribute, if it exists.
|
||||
|
||||
|
||||
Algorithm to initialize SCST from config file
|
||||
---------------------------------------------
|
||||
|
||||
A management utility SHOULD use the following algorithm when doing
|
||||
initial SCST configuration from a config file. All necessary kernel
|
||||
modules and user space programs supposed to be already loaded, hence all
|
||||
dev handlers' entries in /sys/kernel/scst_tgt/handlers as well as all
|
||||
entries for hardware targets already created.
|
||||
|
||||
1. Set stored values for all stored global (/sys/kernel/scst_tgt)
|
||||
attributes.
|
||||
|
||||
2. For each dev driver:
|
||||
|
||||
2.1. Set stored values for all already existing stored attributes.
|
||||
|
||||
2.2. Create not existing stored attributes using "add_attribute" command.
|
||||
|
||||
2.3. For virtual devices dev handlers for each stored device:
|
||||
|
||||
2.3.1. Create the device using "add_device" command using marked read
|
||||
only attributes as parameters.
|
||||
|
||||
2.3.2. Set stored values for all already existing stored attributes.
|
||||
|
||||
2.3.3. Create not existing stored attributes using
|
||||
"add_device_attribute" command.
|
||||
|
||||
2.4. For pass-through dev handlers for each stores device:
|
||||
|
||||
2.4.1. Assign the corresponding pass-through device to this dev handler
|
||||
using "assign" command, if it isn't already auto assigned to it.
|
||||
|
||||
3. For each target driver:
|
||||
|
||||
3.1. Set stored values for all already existing stored attributes.
|
||||
|
||||
3.2. Create not existing stored attributes using "add_attribute" command.
|
||||
|
||||
3.3. For each target:
|
||||
|
||||
3.3.1. For virtual targets:
|
||||
|
||||
3.3.1.1. Create the target using "add_target" command using marked read
|
||||
only attributes as parameters.
|
||||
|
||||
3.3.1.2. Set stored values for all already existing stored attributes.
|
||||
|
||||
3.3.1.3. Create not existing stored attributes using
|
||||
"add_target_attribute" command.
|
||||
|
||||
3.3.2. For hardware targets for each target:
|
||||
|
||||
3.3.2.1. Set stored values for all already existing stored attributes.
|
||||
|
||||
3.3.2.2. Create not existing stored attributes using
|
||||
"add_target_attribute" command.
|
||||
|
||||
3.3.3. Setup LUNs
|
||||
|
||||
3.3.4. Setup ini_groups, their LUNs and initiators' names.
|
||||
|
||||
3.3.5. If this target supports enabling, enable it.
|
||||
|
||||
3.4. If this target driver supports enabling, enable it.
|
||||
|
||||
|
||||
Algorithm to apply changes in config file to currently running SCST
|
||||
-------------------------------------------------------------------
|
||||
|
||||
A management utility SHOULD use the following algorithm when applying
|
||||
changes in config file to currently running SCST.
|
||||
|
||||
Not all changes can be applied on enabled targets or enabled target
|
||||
drivers. From other side, for some target drivers enabling/disabling is
|
||||
a very long and disruptive operation, which should be performed as rare
|
||||
as possible. Thus, the management utility SHOULD support additional
|
||||
option, which, if set, will make it to disable all affected targets
|
||||
before doing any change with them.
|
||||
|
||||
1. Scan all attributes in /sys/kernel/scst_tgt (not requirsive) and
|
||||
compare stored and actual key attributes. Apply all changes.
|
||||
|
||||
2. Scan all subdirectories of /sys/kernel/scst_tgt/handlers. Each
|
||||
subdirectory with "mgmt" attribute is a root subdirectory of a dev
|
||||
handler with name the name of the subdirectory. For each found dev
|
||||
handler do the following:
|
||||
|
||||
2.1. Compare stored and actual key attributes. Apply all changes. Create
|
||||
new attributes using "add_attribute" commands and delete not needed any
|
||||
more attributes using "del_attribute" command.
|
||||
|
||||
2.2. Compare existing devices (links in the root subdirectory pointing
|
||||
to /sys/kernel/scst_tgt/devices) and stored devices in the config file.
|
||||
Delete all not needed devices and create new devices.
|
||||
|
||||
2.3. For all existing devices:
|
||||
|
||||
2.3.1. Compare stored and actual key attributes. Apply all changes.
|
||||
Create new attributes using "add_device_attribute" commands and delete
|
||||
not needed any more attributes using "del_device_attribute" command.
|
||||
|
||||
2.3.2. If any read only key attribute for virtual device should be
|
||||
changed, delete the devices and recreate it.
|
||||
|
||||
2.3.3. For pass-through devices dev handlers reassign handlers if
|
||||
necessary.
|
||||
|
||||
3. Go through all subdirectories in /sys/kernel/scst_tgt/targets. For
|
||||
each target driver:
|
||||
|
||||
3.1. If this target driver should be disabled, disable it.
|
||||
|
||||
3.2. Compare stored and actual key attributes. Apply all changes. Create
|
||||
new attributes using "add_attribute" commands and delete not needed any
|
||||
more attributes using "del_attribute" command.
|
||||
|
||||
3.3. Go through all target's subdirectories. Compare existing and stored
|
||||
targets. Delete all not needed targets and create new targets.
|
||||
|
||||
3.4. For all existing targets:
|
||||
|
||||
3.4.1. If this target should be disabled, disable it.
|
||||
|
||||
3.4.2. Compare stored and actual key attributes. Apply all changes.
|
||||
Create new attributes using "add_target_attribute" commands and delete
|
||||
not needed any more attributes using "del_target_attribute" command.
|
||||
|
||||
3.4.3. If any read only key attribute for virtual target should be
|
||||
changed, delete the target and recreate it.
|
||||
|
||||
3.4.4. Scan all "luns" subdirectory and apply necessary changes, using
|
||||
"replace" commands to replace one LUN by another, if needed.
|
||||
|
||||
3.4.5. Scan all "ini_groups" subdirectories and apply necessary changes,
|
||||
using "replace" commands to replace one LUN by another and "move"
|
||||
command to move initiator from one group to another, if needed. It MUST
|
||||
be done in the following order:
|
||||
|
||||
- Necessary initiators deleted, if they aren't going to be moved
|
||||
|
||||
- LUNs updated
|
||||
|
||||
- Necessary initiators added or moved
|
||||
|
||||
3.4.6. If this target should be enabled, enable it.
|
||||
|
||||
3.5. If this target driver should be enabled, enable it.
|
||||
|
||||
@@ -648,7 +648,7 @@ int scst_create_tgt_sysfs(struct scst_tgt *tgt)
|
||||
goto out;
|
||||
}
|
||||
|
||||
tgt->tgt_ini_grp_kobj = kobject_create_and_add("ini_group",
|
||||
tgt->tgt_ini_grp_kobj = kobject_create_and_add("ini_groups",
|
||||
&tgt->tgt_kobj);
|
||||
if (tgt->tgt_ini_grp_kobj == NULL) {
|
||||
PRINT_ERROR("Can't create ini_grp kobj for tgt %s",
|
||||
@@ -2439,7 +2439,7 @@ static ssize_t scst_setup_id_show(struct kobject *kobj,
|
||||
|
||||
TRACE_ENTRY();
|
||||
|
||||
count = sprintf(buf, "%x%s\n", scst_setup_id,
|
||||
count = sprintf(buf, "0x%x%s\n", scst_setup_id,
|
||||
(scst_setup_id == 0) ? "" : SCST_SYSFS_KEY_MARK "\n");
|
||||
|
||||
TRACE_EXIT();
|
||||
|
||||
Reference in New Issue
Block a user