* [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
@ 2008-09-29 19:21 Nicholas A. Bellinger
2008-10-01 17:36 ` Vladislav Bolkhovitin
2008-10-02 0:18 ` Nicholas A. Bellinger
0 siblings, 2 replies; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-09-29 19:21 UTC (permalink / raw)
To: LKML, linux-scsi, Linux-iSCSI.org Target Dev, SCST-Devel, iet-dev
Cc: Joel Becker, Jerome Martin, Greg KH, James Bottomley,
Vladislav Bolkhovitin, FUJITA Tomonori, Mike Christie,
H. Peter Anvin, Ming Zhang
Greetings all,
I am happy to announce that the first ConfigFS configurable generic
target engine (target_core_mod) and iSCSI Target Stack
(iscsi_target_mod) are now able to use ConfigFS symlinks for the
creation of Linux Storage Objects from drivers/scsi, block, or fs/
storage objects to iSCSI Target Port Endpoints.
The code is available currently running on v2.6.27-rc7 and has been
broken up into a number of commits at:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary
Now that the primary configfs functionality is up and allowing iSCSI
Initiator Traffic to the symlinked storage objects from a generic target
engine, I will be continuing work on the complete logic for configfs
enabled iscsi_target_mod, as well as removing the legacy IOCTL control
path as equivalent functionality is added with ConfigFS.
Also, one of the next major steps for the upstream generic target engine
and iSCSI target stack is to include SCST's target mode API between
Engine / Fabric to give target_core_mod a proper Fabric API to allow
other SCST fabric modules to access target_core_mod's configfs enabled
storage objects. Also, allowing STGT to use the configfs interface to
allow for userspace fabrics to the same target_core_mod storage objects
is also on the list, but I imagine interest from those communities will
certainly help drive those efforts.
Here are the shell variables required to make it all go:
export CONFIGFS=/sys/kernel/config/
export TARGET=/sys/kernel/config/target/core/
export FABRIC=/sys/kernel/config/target/iscsi/
The storage objects registered with target_core_mod via $TARGET may be
mapped from $TARGET/$HBA/$STORAGE_OBJECT any number of times to:
$FABRIC/$IQN/tpgt_1/lun/lun_0/$PORT_LINK
$FABRIC/$IQN/tpgt_1/lun/lun_1/$PORT_LINK
$FABRIC/$IQN/tpgt_2/lun/lun_0/$PORT_LINK
$FABRIC/$ANOTHER_IQN/tpgt_1/lun_0/$PORT_LINK
....
....
Here are the shell commands to bring storage objects online..
# Create a IBLOCK HBA and virtual storage object
mkdir -p $TARGET/iblock_0/lvm_test0
# Tell the virtual storage object what struct block_device we want
echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/dev_control
# Enable the virtual storage object and call bd_claim()
echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable
DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
# Create the network portal on $DEF_IQN/tpgt_1
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
# Create LUN 0 on $DEF_IQN/tpgt_1
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
# Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 0
# to lvm_test0 and give it the port symbolic name of lio_west_port
ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port"
# Allow iSCSI Initiators to login to $DEF_IQN/tpgt_1
#warning Currently uses generate_node_acls=1,cache_dynamic_acls=1,demo_mode_lun_access=1
echo 1 > $FABRIC/$DEF_IQN/tpgt_1/tpg_enable
target:~# tree $CONFIGFS
/sys/kernel/config/
`-- target
|-- core
| `-- iblock_0
| |-- hba_info
| `-- lvm_test0
| |-- dev_control
| |-- dev_enable
| `-- dev_info
|-- iscsi
| |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
| | `-- tpgt_1
| | |-- lun
| | | `-- lun_0
| | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
| | | |-- port_control
| | | `-- port_info
| | |-- np
| | | `-- 172.16.201.137:3260
| | | `-- portal_info
| | |-- tpg_control
| | `-- tpg_enable
| `-- lio_version
`-- version
----------------------------------------------------------
# Add some more HBA and storage Objects
target:~# mkdir -p $TARGET/fileio_0/file_object
target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
target:~# mkdir -p $TARGET/pscsi_0/sdd
target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
# Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
# Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
# to lvm_test0 and give it the port symbolic name of lio_east_port
ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
target:~# tree $CONFIGFS
/sys/kernel/config/
`-- target
|-- core
| |-- fileio_0
| | |-- file_object
| | | |-- dev_control
| | | |-- dev_enable
| | | `-- dev_info
| | `-- hba_info
| |-- iblock_0
| | |-- hba_info
| | `-- lvm_test0
| | |-- dev_control
| | |-- dev_enable
| | `-- dev_info
| |-- pscsi_0
| | |-- hba_info
| | `-- sdd
| | |-- dev_control
| | |-- dev_enable
| | `-- dev_info
| |-- rd_dr_0
| | |-- hba_info
| | `-- ramdisk0
| | |-- dev_control
| | |-- dev_enable
| | `-- dev_info
| `-- rd_mcp_0
| |-- hba_info
| `-- ramdisk0
| |-- dev_control
| |-- dev_enable
| `-- dev_info
|-- iscsi
| |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
| | `-- tpgt_1
| | |-- lun
| | | |-- lun_0
| | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
| | | | |-- port_control
| | | | `-- port_info
| | | `-- lun_1
| | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
| | | |-- port_control
| | | `-- port_info
| | |-- np
| | | `-- 172.16.201.137:3260
| | | `-- portal_info
| | |-- tpg_control
| | `-- tpg_enable
| `-- lio_version
`-- version
22 directories, 29 files
--nab
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-09-29 19:21 [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7 Nicholas A. Bellinger
@ 2008-10-01 17:36 ` Vladislav Bolkhovitin
2008-10-02 0:24 ` Nicholas A. Bellinger
2008-10-02 0:18 ` Nicholas A. Bellinger
1 sibling, 1 reply; 15+ messages in thread
From: Vladislav Bolkhovitin @ 2008-10-01 17:36 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: LKML, linux-scsi, Linux-iSCSI.org Target Dev, SCST-Devel,
iet-dev, Joel Becker, Jerome Martin, Greg KH, James Bottomley,
FUJITA Tomonori, Mike Christie, H. Peter Anvin, Ming Zhang
Hi Nicholas,
Nicholas A. Bellinger wrote:
> Greetings all,
>
> I am happy to announce that the first ConfigFS configurable generic
> target engine (target_core_mod) and iSCSI Target Stack
> (iscsi_target_mod) are now able to use ConfigFS symlinks for the
> creation of Linux Storage Objects from drivers/scsi, block, or fs/
> storage objects to iSCSI Target Port Endpoints.
>
> The code is available currently running on v2.6.27-rc7 and has been
> broken up into a number of commits at:
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary
>
> Now that the primary configfs functionality is up and allowing iSCSI
> Initiator Traffic to the symlinked storage objects from a generic target
> engine, I will be continuing work on the complete logic for configfs
> enabled iscsi_target_mod, as well as removing the legacy IOCTL control
> path as equivalent functionality is added with ConfigFS.
>
> Also, one of the next major steps for the upstream generic target engine
> and iSCSI target stack is to include SCST's target mode API between
> Engine / Fabric to give target_core_mod a proper Fabric API to allow
> other SCST fabric modules to access target_core_mod's configfs enabled
> storage objects. Also, allowing STGT to use the configfs interface to
> allow for userspace fabrics to the same target_core_mod storage objects
> is also on the list, but I imagine interest from those communities will
> certainly help drive those efforts.
>
> Here are the shell variables required to make it all go:
>
> export CONFIGFS=/sys/kernel/config/
> export TARGET=/sys/kernel/config/target/core/
> export FABRIC=/sys/kernel/config/target/iscsi/
>
> The storage objects registered with target_core_mod via $TARGET may be
> mapped from $TARGET/$HBA/$STORAGE_OBJECT any number of times to:
>
> $FABRIC/$IQN/tpgt_1/lun/lun_0/$PORT_LINK
> $FABRIC/$IQN/tpgt_1/lun/lun_1/$PORT_LINK
> $FABRIC/$IQN/tpgt_2/lun/lun_0/$PORT_LINK
> $FABRIC/$ANOTHER_IQN/tpgt_1/lun_0/$PORT_LINK
> ....
> ....
>
> Here are the shell commands to bring storage objects online..
>
> # Create a IBLOCK HBA and virtual storage object
> mkdir -p $TARGET/iblock_0/lvm_test0
> # Tell the virtual storage object what struct block_device we want
> echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/dev_control
> # Enable the virtual storage object and call bd_claim()
> echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable
>
> DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
>
> # Create the network portal on $DEF_IQN/tpgt_1
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
> # Create LUN 0 on $DEF_IQN/tpgt_1
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 0
> # to lvm_test0 and give it the port symbolic name of lio_west_port
> ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port"
>
> # Allow iSCSI Initiators to login to $DEF_IQN/tpgt_1
> #warning Currently uses generate_node_acls=1,cache_dynamic_acls=1,demo_mode_lun_access=1
> echo 1 > $FABRIC/$DEF_IQN/tpgt_1/tpg_enable
>
> target:~# tree $CONFIGFS
> /sys/kernel/config/
> `-- target
> |-- core
> | `-- iblock_0
> | |-- hba_info
> | `-- lvm_test0
> | |-- dev_control
> | |-- dev_enable
> | `-- dev_info
> |-- iscsi
> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> | | `-- tpgt_1
> | | |-- lun
> | | | `-- lun_0
> | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> | | | |-- port_control
> | | | `-- port_info
> | | |-- np
> | | | `-- 172.16.201.137:3260
> | | | `-- portal_info
> | | |-- tpg_control
> | | `-- tpg_enable
> | `-- lio_version
> `-- version
>
>
> ----------------------------------------------------------
>
> # Add some more HBA and storage Objects
> target:~# mkdir -p $TARGET/fileio_0/file_object
> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
>
> target:~# mkdir -p $TARGET/pscsi_0/sdd
> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
>
> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
> # to lvm_test0 and give it the port symbolic name of lio_east_port
> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
>
> target:~# tree $CONFIGFS
> /sys/kernel/config/
> `-- target
> |-- core
> | |-- fileio_0
> | | |-- file_object
> | | | |-- dev_control
> | | | |-- dev_enable
> | | | `-- dev_info
> | | `-- hba_info
> | |-- iblock_0
> | | |-- hba_info
> | | `-- lvm_test0
> | | |-- dev_control
> | | |-- dev_enable
> | | `-- dev_info
> | |-- pscsi_0
> | | |-- hba_info
> | | `-- sdd
> | | |-- dev_control
> | | |-- dev_enable
> | | `-- dev_info
> | |-- rd_dr_0
> | | |-- hba_info
> | | `-- ramdisk0
> | | |-- dev_control
> | | |-- dev_enable
> | | `-- dev_info
> | `-- rd_mcp_0
> | |-- hba_info
> | `-- ramdisk0
> | |-- dev_control
> | |-- dev_enable
> | `-- dev_info
> |-- iscsi
> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> | | `-- tpgt_1
> | | |-- lun
> | | | |-- lun_0
> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> | | | | |-- port_control
> | | | | `-- port_info
> | | | `-- lun_1
> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> | | | |-- port_control
> | | | `-- port_info
> | | |-- np
> | | | `-- 172.16.201.137:3260
> | | | `-- portal_info
> | | |-- tpg_control
> | | `-- tpg_enable
> | `-- lio_version
> `-- version
>
> 22 directories, 29 files
It's good, I like it. The only thing concerns me that, considering how
much time *I* spent to understand it, for an average user understanding
it can be an unbearable nightmare ;)
In a few days I'll write a proposed configfs hierarchy for existing SCST
/proc interface.
Vlad
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-09-29 19:21 [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7 Nicholas A. Bellinger
2008-10-01 17:36 ` Vladislav Bolkhovitin
@ 2008-10-02 0:18 ` Nicholas A. Bellinger
2008-10-02 0:32 ` Nicholas A. Bellinger
1 sibling, 1 reply; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-02 0:18 UTC (permalink / raw)
To: linux-iscsi-target-dev, LKML, linux-scsi, SCST-Devel, iet-dev
Cc: Joel Becker, Jerome Martin, Greg KH, James Bottomley,
Vladislav Bolkhovitin, FUJITA Tomonori, Mike Christie,
H. Peter Anvin, Ming Zhang, Jens Axboe
On Mon, 2008-09-29 at 12:21 -0700, Nicholas A. Bellinger wrote:
> Greetings all,
>
> I am happy to announce that the first ConfigFS configurable generic
> target engine (target_core_mod) and iSCSI Target Stack
> (iscsi_target_mod) are now able to use ConfigFS symlinks for the
> creation of Linux Storage Objects from drivers/scsi, block, or fs/
> storage objects to iSCSI Target Port Endpoints.
>
> The code is available currently running on v2.6.27-rc7 and has been
> broken up into a number of commits at:
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary
>
> Now that the primary configfs functionality is up and allowing iSCSI
> Initiator Traffic to the symlinked storage objects from a generic target
> engine, I will be continuing work on the complete logic for configfs
> enabled iscsi_target_mod, as well as removing the legacy IOCTL control
> path as equivalent functionality is added with ConfigFS.
>
Ok, just added new commits to make target_core_mod be able to run
independently of iscsi_target_mod. This means that all mkdir(2) calls
under $TARGET do not require iscsi_target_mod to be loaded.
Next, following Joel's advice from LPC, I made
target_core_configfs.c:target_core_register_fabric(), call
request_module() to load $FABRIC_MOD instead of using
do_configfs_mkdir() to kick off the registration process. This means
that $FABRIC_MOD's init_module() is responsible for calling
target_fabric_configfs_init() and target_fabric_configfs_register() to
complete $FABRIC_MOD's registration with the configfs generic target
core. This means that startup now looks like:
modprobe target_core_mod
export CONFIGFS=/sys/kernel/config/
export TARGET=/sys/kernel/config/target/core/
export FABRIC=/sys/kernel/config/target/iscsi/
mkdir -p $TARGET/iblock_0/lvm_test0
echo iblock_major=254,iblock_minor=2 >
$TARGET/iblock_0/lvm_test0/dev_control
echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable
mkdir -p $TARGET/pscsi_0/sdd
echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 >
$TARGET/pscsi_0/sdd/dev_control
echo 1 > $TARGET/pscsi_0/sdd/dev_enable
DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
# The first mkdir(2) to $FABRIC will load iscsi_target_mod
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<snip>
This line will modprobe iscsi_target_mod, create iscsi_tiqn_t,
iscsi_portal_group_t, and iscsi_tpg_np_t objects with a single mkdir(2)
call.
Many thanks to Joel Becker for recommending the request_module() usage!
> Also, one of the next major steps for the upstream generic target engine
> and iSCSI target stack is to include SCST's target mode API between
> Engine / Fabric to give target_core_mod a proper Fabric API to allow
> other SCST fabric modules to access target_core_mod's configfs enabled
> storage objects. Also, allowing STGT to use the configfs interface to
> allow for userspace fabrics to the same target_core_mod storage objects
> is also on the list, but I imagine interest from those communities will
> certainly help drive those efforts.
>
So at this point, I believe all (or very close to all) iSCSI target
related functions are now outside of target_core_mod. There are a few
more file and function names that need to have their prefixes changed,
but other that a handful of this minor bits, things are getting close
installing the SCST Target API between $FABRIC_MOD <->
$TARGET_CORE_MOD.
Also, I was thinking a bit more about how things show up under $TARGET,
which is /sys/kernel/config/target/core. With the current code,
parameters are passed it for all target_core_mod subsystem plugins (eg:
the ones to drivers/scsi, block/ or fs/. One thing I was thinking about
for struct scsi_device and struct block_device storage objects that
appear under /sys/block (or any SysFS location that eventually leads
back to a struct scsi_device) would be to create a symbolic link from
say /sys/block/sdd to ConfigFS at say $TARGET/core/pscsi_0/sdd, so we
could drop the echo scsi_channel_id=0,scsi_target_id=0,scsi_lun_id=0 >
$TARGET/pscsi/sdd/dev_control stuff..
I know that ConfigFS today does not allow symlinks to non ConfigFS
filesystems, but perhaps this would be a special case between ConfigFS
<-> SysFS to order to deliver struct scsi_device for $TARGET/pscsi_* and
struct block_device to $TARGET/iblock_* generic storage objects..?
What do you think..? Joel or Greg KH..?
--nab
> Here are the shell variables required to make it all go:
>
> export CONFIGFS=/sys/kernel/config/
> export TARGET=/sys/kernel/config/target/core/
> export FABRIC=/sys/kernel/config/target/iscsi/
>
> The storage objects registered with target_core_mod via $TARGET may be
> mapped from $TARGET/$HBA/$STORAGE_OBJECT any number of times to:
>
> $FABRIC/$IQN/tpgt_1/lun/lun_0/$PORT_LINK
> $FABRIC/$IQN/tpgt_1/lun/lun_1/$PORT_LINK
> $FABRIC/$IQN/tpgt_2/lun/lun_0/$PORT_LINK
> $FABRIC/$ANOTHER_IQN/tpgt_1/lun_0/$PORT_LINK
> ....
> ....
>
> Here are the shell commands to bring storage objects online..
>
> # Create a IBLOCK HBA and virtual storage object
> mkdir -p $TARGET/iblock_0/lvm_test0
> # Tell the virtual storage object what struct block_device we want
> echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/dev_control
> # Enable the virtual storage object and call bd_claim()
> echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable
>
> DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
>
> # Create the network portal on $DEF_IQN/tpgt_1
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
> # Create LUN 0 on $DEF_IQN/tpgt_1
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 0
> # to lvm_test0 and give it the port symbolic name of lio_west_port
> ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port"
>
> # Allow iSCSI Initiators to login to $DEF_IQN/tpgt_1
> #warning Currently uses generate_node_acls=1,cache_dynamic_acls=1,demo_mode_lun_access=1
> echo 1 > $FABRIC/$DEF_IQN/tpgt_1/tpg_enable
>
> target:~# tree $CONFIGFS
> /sys/kernel/config/
> `-- target
> |-- core
> | `-- iblock_0
> | |-- hba_info
> | `-- lvm_test0
> | |-- dev_control
> | |-- dev_enable
> | `-- dev_info
> |-- iscsi
> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> | | `-- tpgt_1
> | | |-- lun
> | | | `-- lun_0
> | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> | | | |-- port_control
> | | | `-- port_info
> | | |-- np
> | | | `-- 172.16.201.137:3260
> | | | `-- portal_info
> | | |-- tpg_control
> | | `-- tpg_enable
> | `-- lio_version
> `-- version
>
>
> ----------------------------------------------------------
>
> # Add some more HBA and storage Objects
> target:~# mkdir -p $TARGET/fileio_0/file_object
> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
>
> target:~# mkdir -p $TARGET/pscsi_0/sdd
> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
>
> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
> # to lvm_test0 and give it the port symbolic name of lio_east_port
> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
>
> target:~# tree $CONFIGFS
> /sys/kernel/config/
> `-- target
> |-- core
> | |-- fileio_0
> | | |-- file_object
> | | | |-- dev_control
> | | | |-- dev_enable
> | | | `-- dev_info
> | | `-- hba_info
> | |-- iblock_0
> | | |-- hba_info
> | | `-- lvm_test0
> | | |-- dev_control
> | | |-- dev_enable
> | | `-- dev_info
> | |-- pscsi_0
> | | |-- hba_info
> | | `-- sdd
> | | |-- dev_control
> | | |-- dev_enable
> | | `-- dev_info
> | |-- rd_dr_0
> | | |-- hba_info
> | | `-- ramdisk0
> | | |-- dev_control
> | | |-- dev_enable
> | | `-- dev_info
> | `-- rd_mcp_0
> | |-- hba_info
> | `-- ramdisk0
> | |-- dev_control
> | |-- dev_enable
> | `-- dev_info
> |-- iscsi
> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> | | `-- tpgt_1
> | | |-- lun
> | | | |-- lun_0
> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> | | | | |-- port_control
> | | | | `-- port_info
> | | | `-- lun_1
> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> | | | |-- port_control
> | | | `-- port_info
> | | |-- np
> | | | `-- 172.16.201.137:3260
> | | | `-- portal_info
> | | |-- tpg_control
> | | `-- tpg_enable
> | `-- lio_version
> `-- version
>
> 22 directories, 29 files
>
> --nab
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Linux-iSCSI.org Target Development" group.
> To post to this group, send email to linux-iscsi-target-dev@googlegroups.com
> To unsubscribe from this group, send email to linux-iscsi-target-dev+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/linux-iscsi-target-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-01 17:36 ` Vladislav Bolkhovitin
@ 2008-10-02 0:24 ` Nicholas A. Bellinger
2008-10-02 17:00 ` Vladislav Bolkhovitin
0 siblings, 1 reply; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-02 0:24 UTC (permalink / raw)
To: linux-iscsi-target-dev
Cc: LKML, linux-scsi, SCST-Devel, iet-dev, Joel Becker,
Jerome Martin, Greg KH, James Bottomley, FUJITA Tomonori,
Mike Christie, H. Peter Anvin, Ming Zhang
On Wed, 2008-10-01 at 21:36 +0400, Vladislav Bolkhovitin wrote:
> Hi Nicholas,
>
> Nicholas A. Bellinger wrote:
> > Greetings all,
> >
> > I am happy to announce that the first ConfigFS configurable generic
> > target engine (target_core_mod) and iSCSI Target Stack
> > (iscsi_target_mod) are now able to use ConfigFS symlinks for the
> > creation of Linux Storage Objects from drivers/scsi, block, or fs/
> > storage objects to iSCSI Target Port Endpoints.
> >
> > The code is available currently running on v2.6.27-rc7 and has been
> > broken up into a number of commits at:
> > http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary
> >
> > Now that the primary configfs functionality is up and allowing iSCSI
> > Initiator Traffic to the symlinked storage objects from a generic target
> > engine, I will be continuing work on the complete logic for configfs
> > enabled iscsi_target_mod, as well as removing the legacy IOCTL control
> > path as equivalent functionality is added with ConfigFS.
> >
> > Also, one of the next major steps for the upstream generic target engine
> > and iSCSI target stack is to include SCST's target mode API between
> > Engine / Fabric to give target_core_mod a proper Fabric API to allow
> > other SCST fabric modules to access target_core_mod's configfs enabled
> > storage objects. Also, allowing STGT to use the configfs interface to
> > allow for userspace fabrics to the same target_core_mod storage objects
> > is also on the list, but I imagine interest from those communities will
> > certainly help drive those efforts.
> >
> > Here are the shell variables required to make it all go:
> >
> > export CONFIGFS=/sys/kernel/config/
> > export TARGET=/sys/kernel/config/target/core/
> > export FABRIC=/sys/kernel/config/target/iscsi/
> >
> > The storage objects registered with target_core_mod via $TARGET may be
> > mapped from $TARGET/$HBA/$STORAGE_OBJECT any number of times to:
> >
> > $FABRIC/$IQN/tpgt_1/lun/lun_0/$PORT_LINK
> > $FABRIC/$IQN/tpgt_1/lun/lun_1/$PORT_LINK
> > $FABRIC/$IQN/tpgt_2/lun/lun_0/$PORT_LINK
> > $FABRIC/$ANOTHER_IQN/tpgt_1/lun_0/$PORT_LINK
> > ....
> > ....
> >
> > Here are the shell commands to bring storage objects online..
> >
> > # Create a IBLOCK HBA and virtual storage object
> > mkdir -p $TARGET/iblock_0/lvm_test0
> > # Tell the virtual storage object what struct block_device we want
> > echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/dev_control
> > # Enable the virtual storage object and call bd_claim()
> > echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable
> >
> > DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
> >
> > # Create the network portal on $DEF_IQN/tpgt_1
> > mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
> > # Create LUN 0 on $DEF_IQN/tpgt_1
> > mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
> > # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 0
> > # to lvm_test0 and give it the port symbolic name of lio_west_port
> > ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port"
> >
> > # Allow iSCSI Initiators to login to $DEF_IQN/tpgt_1
> > #warning Currently uses generate_node_acls=1,cache_dynamic_acls=1,demo_mode_lun_access=1
> > echo 1 > $FABRIC/$DEF_IQN/tpgt_1/tpg_enable
> >
> > target:~# tree $CONFIGFS
> > /sys/kernel/config/
> > `-- target
> > |-- core
> > | `-- iblock_0
> > | |-- hba_info
> > | `-- lvm_test0
> > | |-- dev_control
> > | |-- dev_enable
> > | `-- dev_info
> > |-- iscsi
> > | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> > | | `-- tpgt_1
> > | | |-- lun
> > | | | `-- lun_0
> > | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> > | | | |-- port_control
> > | | | `-- port_info
> > | | |-- np
> > | | | `-- 172.16.201.137:3260
> > | | | `-- portal_info
> > | | |-- tpg_control
> > | | `-- tpg_enable
> > | `-- lio_version
> > `-- version
> >
> >
> > ----------------------------------------------------------
> >
> > # Add some more HBA and storage Objects
> > target:~# mkdir -p $TARGET/fileio_0/file_object
> > target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
> > target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
> >
> > target:~# mkdir -p $TARGET/pscsi_0/sdd
> > target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
> > target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
> >
> > # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
> > mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> > # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
> > # to lvm_test0 and give it the port symbolic name of lio_east_port
> > ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
> >
> > target:~# tree $CONFIGFS
> > /sys/kernel/config/
> > `-- target
> > |-- core
> > | |-- fileio_0
> > | | |-- file_object
> > | | | |-- dev_control
> > | | | |-- dev_enable
> > | | | `-- dev_info
> > | | `-- hba_info
> > | |-- iblock_0
> > | | |-- hba_info
> > | | `-- lvm_test0
> > | | |-- dev_control
> > | | |-- dev_enable
> > | | `-- dev_info
> > | |-- pscsi_0
> > | | |-- hba_info
> > | | `-- sdd
> > | | |-- dev_control
> > | | |-- dev_enable
> > | | `-- dev_info
> > | |-- rd_dr_0
> > | | |-- hba_info
> > | | `-- ramdisk0
> > | | |-- dev_control
> > | | |-- dev_enable
> > | | `-- dev_info
> > | `-- rd_mcp_0
> > | |-- hba_info
> > | `-- ramdisk0
> > | |-- dev_control
> > | |-- dev_enable
> > | `-- dev_info
> > |-- iscsi
> > | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> > | | `-- tpgt_1
> > | | |-- lun
> > | | | |-- lun_0
> > | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> > | | | | |-- port_control
> > | | | | `-- port_info
> > | | | `-- lun_1
> > | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> > | | | |-- port_control
> > | | | `-- port_info
> > | | |-- np
> > | | | `-- 172.16.201.137:3260
> > | | | `-- portal_info
> > | | |-- tpg_control
> > | | `-- tpg_enable
> > | `-- lio_version
> > `-- version
> >
> > 22 directories, 29 files
>
> It's good, I like it. The only thing concerns me that, considering how
> much time *I* spent to understand it, for an average user understanding
> it can be an unbearable nightmare ;)
>
Well, the idea is not necessarily making the configfs interface the
easiest to use in the world by user directly through $CONFIGFS, but to
make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
actual UIs for user that interact with generic target core and
$FABRIC_MODs be as simple and elegent as possible.
That is what I believe the balance that a configfs enabled generic
target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
maintainers looking to port their code to use a generic control
infrastructure. :-)
> In a few days I'll write a proposed configfs hierarchy for existing SCST
> /proc interface.
>
Sounds good! Please let me know if you have questions.
--nab
> Vlad
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Linux-iSCSI.org Target Development" group.
> To post to this group, send email to linux-iscsi-target-dev@googlegroups.com
> To unsubscribe from this group, send email to linux-iscsi-target-dev+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/linux-iscsi-target-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-02 0:18 ` Nicholas A. Bellinger
@ 2008-10-02 0:32 ` Nicholas A. Bellinger
0 siblings, 0 replies; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-02 0:32 UTC (permalink / raw)
To: linux-iscsi-target-dev
Cc: LKML, linux-scsi, SCST-Devel, iet-dev, Joel Becker,
Jerome Martin, Greg KH, James Bottomley, Vladislav Bolkhovitin,
FUJITA Tomonori, Mike Christie, H. Peter Anvin, Ming Zhang,
Jens Axboe
On Wed, 2008-10-01 at 17:18 -0700, Nicholas A. Bellinger wrote:
> On Mon, 2008-09-29 at 12:21 -0700, Nicholas A. Bellinger wrote:
> > Greetings all,
> >
> > I am happy to announce that the first ConfigFS configurable generic
> > target engine (target_core_mod) and iSCSI Target Stack
> > (iscsi_target_mod) are now able to use ConfigFS symlinks for the
> > creation of Linux Storage Objects from drivers/scsi, block, or fs/
> > storage objects to iSCSI Target Port Endpoints.
> >
> > The code is available currently running on v2.6.27-rc7 and has been
> > broken up into a number of commits at:
> > http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary
> >
> > Now that the primary configfs functionality is up and allowing iSCSI
> > Initiator Traffic to the symlinked storage objects from a generic target
> > engine, I will be continuing work on the complete logic for configfs
> > enabled iscsi_target_mod, as well as removing the legacy IOCTL control
> > path as equivalent functionality is added with ConfigFS.
> >
>
> Ok, just added new commits to make target_core_mod be able to run
> independently of iscsi_target_mod. This means that all mkdir(2) calls
> under $TARGET do not require iscsi_target_mod to be loaded.
>
> Next, following Joel's advice from LPC, I made
> target_core_configfs.c:target_core_register_fabric(), call
> request_module() to load $FABRIC_MOD instead of using
> do_configfs_mkdir() to kick off the registration process. This means
> that $FABRIC_MOD's init_module() is responsible for calling
> target_fabric_configfs_init() and target_fabric_configfs_register() to
> complete $FABRIC_MOD's registration with the configfs generic target
> core. This means that startup now looks like:
>
> modprobe target_core_mod
>
> export CONFIGFS=/sys/kernel/config/
> export TARGET=/sys/kernel/config/target/core/
> export FABRIC=/sys/kernel/config/target/iscsi/
>
> mkdir -p $TARGET/iblock_0/lvm_test0
> echo iblock_major=254,iblock_minor=2 >
> $TARGET/iblock_0/lvm_test0/dev_control
> echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable
>
> mkdir -p $TARGET/pscsi_0/sdd
> echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 >
> $TARGET/pscsi_0/sdd/dev_control
> echo 1 > $TARGET/pscsi_0/sdd/dev_enable
>
> DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
>
> # The first mkdir(2) to $FABRIC will load iscsi_target_mod
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> <snip>
>
> This line will modprobe iscsi_target_mod, create iscsi_tiqn_t,
> iscsi_portal_group_t, and iscsi_tpg_np_t objects with a single mkdir(2)
> call.
>
> Many thanks to Joel Becker for recommending the request_module() usage!
>
> > Also, one of the next major steps for the upstream generic target engine
> > and iSCSI target stack is to include SCST's target mode API between
> > Engine / Fabric to give target_core_mod a proper Fabric API to allow
> > other SCST fabric modules to access target_core_mod's configfs enabled
> > storage objects. Also, allowing STGT to use the configfs interface to
> > allow for userspace fabrics to the same target_core_mod storage objects
> > is also on the list, but I imagine interest from those communities will
> > certainly help drive those efforts.
> >
>
> So at this point, I believe all (or very close to all) iSCSI target
> related functions are now outside of target_core_mod. There are a few
> more file and function names that need to have their prefixes changed,
> but other that a handful of this minor bits, things are getting close
> installing the SCST Target API between $FABRIC_MOD <->
> $TARGET_CORE_MOD.
>
> Also, I was thinking a bit more about how things show up under $TARGET,
> which is /sys/kernel/config/target/core. With the current code,
> parameters are passed it for all target_core_mod subsystem plugins (eg:
> the ones to drivers/scsi, block/ or fs/. One thing I was thinking about
> for struct scsi_device and struct block_device storage objects that
> appear under /sys/block (or any SysFS location that eventually leads
> back to a struct scsi_device) would be to create a symbolic link from
> say /sys/block/sdd to ConfigFS at say $TARGET/core/pscsi_0/sdd, so we
> could drop the echo scsi_channel_id=0,scsi_target_id=0,scsi_lun_id=0 >
> $TARGET/pscsi/sdd/dev_control stuff..
>
> I know that ConfigFS today does not allow symlinks to non ConfigFS
> filesystems, but perhaps this would be a special case between ConfigFS
> <-> SysFS to order to deliver struct scsi_device for $TARGET/pscsi_* and
> struct block_device to $TARGET/iblock_* generic storage objects..?
>
This last part should be:
".. a special case between ConfigFS <-> SysFS in order to deliver struct
scsi_device and struct block_device via SymLinks to
$TARGET/pscsi_*/$STORAGE_OBJECT and
$TARGET/iblock_*/$STORAGE_OBJECT respectively.
>From there, $STORAGE_OBJECT would be SymLinked again to $PORT_LINK at:
ln -s $TARGET/$PLUGIN_HBA/$STORAGE_OBJECT
$FABRIC/endpoint/lun/lun_0/lio_west_port
--nab
> What do you think..? Joel or Greg KH..?
>
> --nab
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-02 0:24 ` Nicholas A. Bellinger
@ 2008-10-02 17:00 ` Vladislav Bolkhovitin
2008-10-02 21:29 ` Nicholas A. Bellinger
0 siblings, 1 reply; 15+ messages in thread
From: Vladislav Bolkhovitin @ 2008-10-02 17:00 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
Nicholas A. Bellinger wrote:
>>> # Add some more HBA and storage Objects
>>> target:~# mkdir -p $TARGET/fileio_0/file_object
>>> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
>>> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
>>>
>>> target:~# mkdir -p $TARGET/pscsi_0/sdd
>>> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
>>> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
>>>
>>> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
>>> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
>>> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
>>> # to lvm_test0 and give it the port symbolic name of lio_east_port
>>> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
>>>
>>> target:~# tree $CONFIGFS
>>> /sys/kernel/config/
>>> `-- target
>>> |-- core
>>> | |-- fileio_0
>>> | | |-- file_object
>>> | | | |-- dev_control
>>> | | | |-- dev_enable
>>> | | | `-- dev_info
>>> | | `-- hba_info
>>> | |-- iblock_0
>>> | | |-- hba_info
>>> | | `-- lvm_test0
>>> | | |-- dev_control
>>> | | |-- dev_enable
>>> | | `-- dev_info
>>> | |-- pscsi_0
>>> | | |-- hba_info
>>> | | `-- sdd
>>> | | |-- dev_control
>>> | | |-- dev_enable
>>> | | `-- dev_info
>>> | |-- rd_dr_0
>>> | | |-- hba_info
>>> | | `-- ramdisk0
>>> | | |-- dev_control
>>> | | |-- dev_enable
>>> | | `-- dev_info
>>> | `-- rd_mcp_0
>>> | |-- hba_info
>>> | `-- ramdisk0
>>> | |-- dev_control
>>> | |-- dev_enable
>>> | `-- dev_info
>>> |-- iscsi
>>> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
>>> | | `-- tpgt_1
>>> | | |-- lun
>>> | | | |-- lun_0
>>> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
>>> | | | | |-- port_control
>>> | | | | `-- port_info
>>> | | | `-- lun_1
>>> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
>>> | | | |-- port_control
>>> | | | `-- port_info
>>> | | |-- np
>>> | | | `-- 172.16.201.137:3260
>>> | | | `-- portal_info
>>> | | |-- tpg_control
>>> | | `-- tpg_enable
>>> | `-- lio_version
>>> `-- version
>>>
>>> 22 directories, 29 files
>> It's good, I like it. The only thing concerns me that, considering how
>> much time *I* spent to understand it, for an average user understanding
>> it can be an unbearable nightmare ;)
>>
>
> Well, the idea is not necessarily making the configfs interface the
> easiest to use in the world by user directly through $CONFIGFS, but to
> make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
> actual UIs for user that interact with generic target core and
> $FABRIC_MODs be as simple and elegent as possible.
>
> That is what I believe the balance that a configfs enabled generic
> target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
> maintainers looking to port their code to use a generic control
> infrastructure. :-)
>
>> In a few days I'll write a proposed configfs hierarchy for existing SCST
>> /proc interface.
>
> Sounds good! Please let me know if you have questions.
There's one unsolved problem. As I've already written, SCST core needs
an ability to provide to user space a large amount of data, which may
not fit to a single page. A list of connected initiators ("sessions"
file in /proc), for instance. Each initiator in that list has a number
of attributes: initiator name, target template name, count of
outstanding commands, etc. The logical way for that would be to create a
subdirectory for each initiator, like:
/sys/kernel/config/
`-- target
`-- sessions
`-- session1
| |-- initiator_name
| |-- template_name
| `-- commands
|
`-- session2
|-- initiator_name
`-- template_name
`-- commands
But looks like configfs requires each subdirectory to be created
manually by user via, e.g., mkdir command. It would be really strange if
we require user to manually create "sessions" subdirectory to be able to
see a list of connected initiators. Do I miss anything?
Vlad
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-02 17:00 ` Vladislav Bolkhovitin
@ 2008-10-02 21:29 ` Nicholas A. Bellinger
2008-10-03 23:14 ` Nicholas A. Bellinger
2008-10-07 9:56 ` Vladislav Bolkhovitin
0 siblings, 2 replies; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-02 21:29 UTC (permalink / raw)
To: Vladislav Bolkhovitin
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
On Thu, 2008-10-02 at 21:00 +0400, Vladislav Bolkhovitin wrote:
> Nicholas A. Bellinger wrote:
> >>> # Add some more HBA and storage Objects
> >>> target:~# mkdir -p $TARGET/fileio_0/file_object
> >>> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
> >>> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
> >>>
> >>> target:~# mkdir -p $TARGET/pscsi_0/sdd
> >>> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
> >>> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
> >>>
> >>> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
> >>> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> >>> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
> >>> # to lvm_test0 and give it the port symbolic name of lio_east_port
> >>> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
> >>>
> >>> target:~# tree $CONFIGFS
> >>> /sys/kernel/config/
> >>> `-- target
> >>> |-- core
> >>> | |-- fileio_0
> >>> | | |-- file_object
> >>> | | | |-- dev_control
> >>> | | | |-- dev_enable
> >>> | | | `-- dev_info
> >>> | | `-- hba_info
> >>> | |-- iblock_0
> >>> | | |-- hba_info
> >>> | | `-- lvm_test0
> >>> | | |-- dev_control
> >>> | | |-- dev_enable
> >>> | | `-- dev_info
> >>> | |-- pscsi_0
> >>> | | |-- hba_info
> >>> | | `-- sdd
> >>> | | |-- dev_control
> >>> | | |-- dev_enable
> >>> | | `-- dev_info
> >>> | |-- rd_dr_0
> >>> | | |-- hba_info
> >>> | | `-- ramdisk0
> >>> | | |-- dev_control
> >>> | | |-- dev_enable
> >>> | | `-- dev_info
> >>> | `-- rd_mcp_0
> >>> | |-- hba_info
> >>> | `-- ramdisk0
> >>> | |-- dev_control
> >>> | |-- dev_enable
> >>> | `-- dev_info
> >>> |-- iscsi
> >>> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> >>> | | `-- tpgt_1
> >>> | | |-- lun
> >>> | | | |-- lun_0
> >>> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> >>> | | | | |-- port_control
> >>> | | | | `-- port_info
> >>> | | | `-- lun_1
> >>> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> >>> | | | |-- port_control
> >>> | | | `-- port_info
> >>> | | |-- np
> >>> | | | `-- 172.16.201.137:3260
> >>> | | | `-- portal_info
> >>> | | |-- tpg_control
> >>> | | `-- tpg_enable
> >>> | `-- lio_version
> >>> `-- version
> >>>
> >>> 22 directories, 29 files
> >> It's good, I like it. The only thing concerns me that, considering how
> >> much time *I* spent to understand it, for an average user understanding
> >> it can be an unbearable nightmare ;)
> >>
> >
> > Well, the idea is not necessarily making the configfs interface the
> > easiest to use in the world by user directly through $CONFIGFS, but to
> > make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
> > actual UIs for user that interact with generic target core and
> > $FABRIC_MODs be as simple and elegent as possible.
> >
> > That is what I believe the balance that a configfs enabled generic
> > target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
> > maintainers looking to port their code to use a generic control
> > infrastructure. :-)
> >
> >> In a few days I'll write a proposed configfs hierarchy for existing SCST
> >> /proc interface.
> >
> > Sounds good! Please let me know if you have questions.
>
> There's one unsolved problem. As I've already written, SCST core needs
> an ability to provide to user space a large amount of data, which may
> not fit to a single page.
>
> A list of connected initiators ("sessions"
> file in /proc), for instance. Each initiator in that list has a number
> of attributes: initiator name, target template name, count of
> outstanding commands, etc. The logical way for that would be to create a
> subdirectory for each initiator, like:
>
> /sys/kernel/config/
> `-- target
> `-- sessions
> `-- session1
> | |-- initiator_name
> | |-- template_name
> | `-- commands
> |
> `-- session2
> |-- initiator_name
> `-- template_name
> `-- commands
>
The the Initiator Port ACLs need to go
under /sys/kernel/config/target/$FABRIC because the struct fabric_acl *
will always contain fabric dependent config items. For example, Since
these struct fabric_acl_t do *NOT* symlink directly back to
target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to
fabric_lun_t (iscsi_lun_t in my case) to Symlink to
a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with
the generic target configfs infrastructure.
Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI
Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to
those Portal Groups. There are two cases:
*) The production case with with user creating those ACLs under $FABRIC
(which is what I will focus on now).
* And "Demo Mode" case where any Initiator logging into
$FABRIC/$ENDPOINT/$PORTAL can have access to all
$FABRIC/$ENDPOINT/lun/lun_*/*my_ports*
The production ACL case would look like:
export CONFIGFS=/sys/kernel/config/
export TARGET=/sys/kernel/config/target/core/
export FABRIC=/sys/kernel/config/target/iscsi/
TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec
INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f
<Setup $STORAGE_OBJECTs under $TARGET>
# Create the LIO-target endpoint
mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260"
mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0"
<Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0>
# Create the Initiator ACL under $TARGET_IQN/tpgt_1
mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN"
# Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/
ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \
"$FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN/lun_0"
>From there, you don't have to worry about PAGE_SIZE limitiations w/o, I
can simply use use:
cat $FABRIC/iqn*/tpgt*/initiators/*/session
to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target
Ports.
Also I should add that I am currently using /proc/scsi_target/mib
and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko
and iscsi_target_mod.ko respectively. For the other "Demo Mode" case
mentioned above, I am currently using /proc/iscsi_target/mib/sess_attr
to see the active sessions for LIO-Target.
I will be implementing this model over the next days.. I will post the
commit once its up and you can have a look..
--nab
>
>
> But looks like configfs requires each subdirectory to be created
> manually by user via, e.g., mkdir command. It would be really strange if
> we require user to manually create "sessions" subdirectory to be able to
> see a list of connected initiators. Do I miss anything?
>
> Vlad
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-02 21:29 ` Nicholas A. Bellinger
@ 2008-10-03 23:14 ` Nicholas A. Bellinger
2008-10-07 9:56 ` Vladislav Bolkhovitin
1 sibling, 0 replies; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-03 23:14 UTC (permalink / raw)
To: linux-iscsi-target-dev
Cc: Vladislav Bolkhovitin, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
On Thu, 2008-10-02 at 14:29 -0700, Nicholas A. Bellinger wrote:
> On Thu, 2008-10-02 at 21:00 +0400, Vladislav Bolkhovitin wrote:
> > Nicholas A. Bellinger wrote:
> > >>> # Add some more HBA and storage Objects
> > >>> target:~# mkdir -p $TARGET/fileio_0/file_object
> > >>> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
> > >>> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
> > >>>
> > >>> target:~# mkdir -p $TARGET/pscsi_0/sdd
> > >>> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
> > >>> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
> > >>>
> > >>> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
> > >>> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> > >>> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
> > >>> # to lvm_test0 and give it the port symbolic name of lio_east_port
> > >>> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
> > >>>
> > >>> target:~# tree $CONFIGFS
> > >>> /sys/kernel/config/
> > >>> `-- target
> > >>> |-- core
> > >>> | |-- fileio_0
> > >>> | | |-- file_object
> > >>> | | | |-- dev_control
> > >>> | | | |-- dev_enable
> > >>> | | | `-- dev_info
> > >>> | | `-- hba_info
> > >>> | |-- iblock_0
> > >>> | | |-- hba_info
> > >>> | | `-- lvm_test0
> > >>> | | |-- dev_control
> > >>> | | |-- dev_enable
> > >>> | | `-- dev_info
> > >>> | |-- pscsi_0
> > >>> | | |-- hba_info
> > >>> | | `-- sdd
> > >>> | | |-- dev_control
> > >>> | | |-- dev_enable
> > >>> | | `-- dev_info
> > >>> | |-- rd_dr_0
> > >>> | | |-- hba_info
> > >>> | | `-- ramdisk0
> > >>> | | |-- dev_control
> > >>> | | |-- dev_enable
> > >>> | | `-- dev_info
> > >>> | `-- rd_mcp_0
> > >>> | |-- hba_info
> > >>> | `-- ramdisk0
> > >>> | |-- dev_control
> > >>> | |-- dev_enable
> > >>> | `-- dev_info
> > >>> |-- iscsi
> > >>> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> > >>> | | `-- tpgt_1
> > >>> | | |-- lun
> > >>> | | | |-- lun_0
> > >>> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> > >>> | | | | |-- port_control
> > >>> | | | | `-- port_info
> > >>> | | | `-- lun_1
> > >>> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> > >>> | | | |-- port_control
> > >>> | | | `-- port_info
> > >>> | | |-- np
> > >>> | | | `-- 172.16.201.137:3260
> > >>> | | | `-- portal_info
> > >>> | | |-- tpg_control
> > >>> | | `-- tpg_enable
> > >>> | `-- lio_version
> > >>> `-- version
> > >>>
> > >>> 22 directories, 29 files
> > >> It's good, I like it. The only thing concerns me that, considering how
> > >> much time *I* spent to understand it, for an average user understanding
> > >> it can be an unbearable nightmare ;)
> > >>
> > >
> > > Well, the idea is not necessarily making the configfs interface the
> > > easiest to use in the world by user directly through $CONFIGFS, but to
> > > make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
> > > actual UIs for user that interact with generic target core and
> > > $FABRIC_MODs be as simple and elegent as possible.
> > >
> > > That is what I believe the balance that a configfs enabled generic
> > > target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
> > > maintainers looking to port their code to use a generic control
> > > infrastructure. :-)
> > >
> > >> In a few days I'll write a proposed configfs hierarchy for existing SCST
> > >> /proc interface.
> > >
> > > Sounds good! Please let me know if you have questions.
> >
> > There's one unsolved problem. As I've already written, SCST core needs
> > an ability to provide to user space a large amount of data, which may
> > not fit to a single page.
> >
> > A list of connected initiators ("sessions"
> > file in /proc), for instance. Each initiator in that list has a number
> > of attributes: initiator name, target template name, count of
> > outstanding commands, etc. The logical way for that would be to create a
> > subdirectory for each initiator, like:
> >
> > /sys/kernel/config/
> > `-- target
> > `-- sessions
> > `-- session1
> > | |-- initiator_name
> > | |-- template_name
> > | `-- commands
> > |
> > `-- session2
> > |-- initiator_name
> > `-- template_name
> > `-- commands
> >
>
> The the Initiator Port ACLs need to go
> under /sys/kernel/config/target/$FABRIC because the struct fabric_acl *
> will always contain fabric dependent config items. For example, Since
> these struct fabric_acl_t do *NOT* symlink directly back to
> target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to
> fabric_lun_t (iscsi_lun_t in my case) to Symlink to
> a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with
> the generic target configfs infrastructure.
>
> Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI
> Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to
> those Portal Groups. There are two cases:
>
> *) The production case with with user creating those ACLs under $FABRIC
> (which is what I will focus on now).
>
> * And "Demo Mode" case where any Initiator logging into
> $FABRIC/$ENDPOINT/$PORTAL can have access to all
> $FABRIC/$ENDPOINT/lun/lun_*/*my_ports*
>
> The production ACL case would look like:
>
> export CONFIGFS=/sys/kernel/config/
> export TARGET=/sys/kernel/config/target/core/
> export FABRIC=/sys/kernel/config/target/iscsi/
>
> TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec
> INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f
>
> <Setup $STORAGE_OBJECTs under $TARGET>
>
> # Create the LIO-target endpoint
> mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260"
> mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0"
>
> <Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0>
>
> # Create the Initiator ACL under $TARGET_IQN/tpgt_1
> mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN"
> # Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/
> ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \
> "$FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN/lun_0"
>
> >From there, you don't have to worry about PAGE_SIZE limitiations w/o, I
> can simply use use:
>
> cat $FABRIC/iqn*/tpgt*/initiators/*/session
>
> to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target
> Ports.
>
> Also I should add that I am currently using /proc/scsi_target/mib
> and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko
> and iscsi_target_mod.ko respectively. For the other "Demo Mode" case
> mentioned above, I am currently using /proc/iscsi_target/mib/sess_attr
> to see the active sessions for LIO-Target.
>
> I will be implementing this model over the next days.. I will post the
> commit once its up and you can have a look..
>
Ok, here is the commit diff for adding Initiator ACLS to
iscsi/$IQN/$TPGT/ under the acls/ subdirectory (instead of "initiators"
in the example above).
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commitdiff;h=0a451affbe236b5538e5de06242372715e3ac52c;hp=374e8ace84ca58490be22d881f017d48c6742b50
Other than the name change, everything is functioning in the commit as
described in the example above. I am able to successfully mkdir(2) and
rmdir(2) iscsi/$IQN/$TPGT/acls/$INITIATOR_IQN, as well as create the
SymLinks from iscsi/$IQN/$TPGT/lun/lun_* to
iscsi/$IQN/$TPGT/acls/$INITIATOR_IQN/lun_* to create the Initiator TPGT
LUN Mappings.
There are a couple of remaining items that I am still working on WRT the
Initiator ACL code. One is that the CmdSN Queue Depth for the Initiator
is hardcoded. This needs to be a configfs attribute under
iscsi/$IQN/$TPGT/acls/$INITIATOR_NAME/, and then enabled with a
attribute under the same $INITIATOR_NAME directory. Another is
assigning READ-ONLY (its hardcoded to R/W for now) access to one of the
initiator's TPG LUN mappings. I was thinking name in the TPG LUN
Symlink destination name, we could include "lun_0:RO" in order to make
this Initiator's LUN be READ-ONLY.
Anyways, this are pretty minor and I should be commiting the remaining
pieces over the weekend.
--nab
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-02 21:29 ` Nicholas A. Bellinger
2008-10-03 23:14 ` Nicholas A. Bellinger
@ 2008-10-07 9:56 ` Vladislav Bolkhovitin
2008-10-07 20:50 ` Nicholas A. Bellinger
1 sibling, 1 reply; 15+ messages in thread
From: Vladislav Bolkhovitin @ 2008-10-07 9:56 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
Nicholas A. Bellinger wrote:
> On Thu, 2008-10-02 at 21:00 +0400, Vladislav Bolkhovitin wrote:
>> Nicholas A. Bellinger wrote:
>>>>> # Add some more HBA and storage Objects
>>>>> target:~# mkdir -p $TARGET/fileio_0/file_object
>>>>> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
>>>>> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
>>>>>
>>>>> target:~# mkdir -p $TARGET/pscsi_0/sdd
>>>>> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
>>>>> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
>>>>>
>>>>> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
>>>>> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
>>>>> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
>>>>> # to lvm_test0 and give it the port symbolic name of lio_east_port
>>>>> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
>>>>>
>>>>> target:~# tree $CONFIGFS
>>>>> /sys/kernel/config/
>>>>> `-- target
>>>>> |-- core
>>>>> | |-- fileio_0
>>>>> | | |-- file_object
>>>>> | | | |-- dev_control
>>>>> | | | |-- dev_enable
>>>>> | | | `-- dev_info
>>>>> | | `-- hba_info
>>>>> | |-- iblock_0
>>>>> | | |-- hba_info
>>>>> | | `-- lvm_test0
>>>>> | | |-- dev_control
>>>>> | | |-- dev_enable
>>>>> | | `-- dev_info
>>>>> | |-- pscsi_0
>>>>> | | |-- hba_info
>>>>> | | `-- sdd
>>>>> | | |-- dev_control
>>>>> | | |-- dev_enable
>>>>> | | `-- dev_info
>>>>> | |-- rd_dr_0
>>>>> | | |-- hba_info
>>>>> | | `-- ramdisk0
>>>>> | | |-- dev_control
>>>>> | | |-- dev_enable
>>>>> | | `-- dev_info
>>>>> | `-- rd_mcp_0
>>>>> | |-- hba_info
>>>>> | `-- ramdisk0
>>>>> | |-- dev_control
>>>>> | |-- dev_enable
>>>>> | `-- dev_info
>>>>> |-- iscsi
>>>>> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
>>>>> | | `-- tpgt_1
>>>>> | | |-- lun
>>>>> | | | |-- lun_0
>>>>> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
>>>>> | | | | |-- port_control
>>>>> | | | | `-- port_info
>>>>> | | | `-- lun_1
>>>>> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
>>>>> | | | |-- port_control
>>>>> | | | `-- port_info
>>>>> | | |-- np
>>>>> | | | `-- 172.16.201.137:3260
>>>>> | | | `-- portal_info
>>>>> | | |-- tpg_control
>>>>> | | `-- tpg_enable
>>>>> | `-- lio_version
>>>>> `-- version
>>>>>
>>>>> 22 directories, 29 files
>>>> It's good, I like it. The only thing concerns me that, considering how
>>>> much time *I* spent to understand it, for an average user understanding
>>>> it can be an unbearable nightmare ;)
>>>>
>>> Well, the idea is not necessarily making the configfs interface the
>>> easiest to use in the world by user directly through $CONFIGFS, but to
>>> make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
>>> actual UIs for user that interact with generic target core and
>>> $FABRIC_MODs be as simple and elegent as possible.
>>>
>>> That is what I believe the balance that a configfs enabled generic
>>> target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
>>> maintainers looking to port their code to use a generic control
>>> infrastructure. :-)
>>>
>>>> In a few days I'll write a proposed configfs hierarchy for existing SCST
>>>> /proc interface.
>>> Sounds good! Please let me know if you have questions.
>> There's one unsolved problem. As I've already written, SCST core needs
>> an ability to provide to user space a large amount of data, which may
>> not fit to a single page.
>>
>> A list of connected initiators ("sessions"
>> file in /proc), for instance. Each initiator in that list has a number
>> of attributes: initiator name, target template name, count of
>> outstanding commands, etc. The logical way for that would be to create a
>> subdirectory for each initiator, like:
>>
>> /sys/kernel/config/
>> `-- target
>> `-- sessions
>> `-- session1
>> | |-- initiator_name
>> | |-- template_name
>> | `-- commands
>> |
>> `-- session2
>> |-- initiator_name
>> `-- template_name
>> `-- commands
>>
>
> The the Initiator Port ACLs need to go
> under /sys/kernel/config/target/$FABRIC because the struct fabric_acl *
> will always contain fabric dependent config items. For example, Since
> these struct fabric_acl_t do *NOT* symlink directly back to
> target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to
> fabric_lun_t (iscsi_lun_t in my case) to Symlink to
> a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with
> the generic target configfs infrastructure.
>
> Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI
> Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to
> those Portal Groups. There are two cases:
>
> *) The production case with with user creating those ACLs under $FABRIC
> (which is what I will focus on now).
>
> * And "Demo Mode" case where any Initiator logging into
> $FABRIC/$ENDPOINT/$PORTAL can have access to all
> $FABRIC/$ENDPOINT/lun/lun_*/*my_ports*
>
> The production ACL case would look like:
>
> export CONFIGFS=/sys/kernel/config/
> export TARGET=/sys/kernel/config/target/core/
> export FABRIC=/sys/kernel/config/target/iscsi/
>
> TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec
> INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f
>
> <Setup $STORAGE_OBJECTs under $TARGET>
>
> # Create the LIO-target endpoint
> mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260"
> mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0"
>
> <Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0>
>
> # Create the Initiator ACL under $TARGET_IQN/tpgt_1
> mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN"
> # Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/
> ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \
> "$FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN/lun_0"
>
>>From there, you don't have to worry about PAGE_SIZE limitiations w/o, I
> can simply use use:
>
> cat $FABRIC/iqn*/tpgt*/initiators/*/session
>
> to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target
> Ports.
>
> Also I should add that I am currently using /proc/scsi_target/mib
> and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko
> and iscsi_target_mod.ko respectively. For the other "Demo Mode" case
> mentioned above, I am currently using /proc/iscsi_target/mib/sess_attr
> to see the active sessions for LIO-Target.
Sorry for the delay. I didn't have a chance to look at it sufficiently
close.
Basically the idea about how to manage ACLs is good, but I don't like,
that with it *ALL* the target drivers would have to implement the
necessary code. It shouldn't be so, management of all security stuff
should be purely duty of the mid-layer. And this is exactly implemented
in SCST. All what target drivers should do with it is to pass target's
name on its registration in scst_register() and then while registering a
session with remote initiator using scst_register_session() pass to it
the initiator's name. Everything else is done by the SCST core.
Thus, I believe, all the ACL management should be done not in $FABRIC/,
but in $TARGET/. It would remove all the corresponding configfs
headaches from the target drivers writers.
But, in fact, I asked about completely different thing. SCSI target
mid-layer in some cases needs to export in user space amount of data,
which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What
should we do for it?
> I will be implementing this model over the next days.. I will post the
> commit once its up and you can have a look..
>
> --nab
>
>>
>> But looks like configfs requires each subdirectory to be created
>> manually by user via, e.g., mkdir command. It would be really strange if
>> we require user to manually create "sessions" subdirectory to be able to
>> see a list of connected initiators. Do I miss anything?
>>
>> Vlad
>>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-07 9:56 ` Vladislav Bolkhovitin
@ 2008-10-07 20:50 ` Nicholas A. Bellinger
2008-10-08 7:22 ` Nicholas A. Bellinger
2008-10-10 17:48 ` Vladislav Bolkhovitin
0 siblings, 2 replies; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-07 20:50 UTC (permalink / raw)
To: Vladislav Bolkhovitin
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
On Tue, 2008-10-07 at 13:56 +0400, Vladislav Bolkhovitin wrote:
> Nicholas A. Bellinger wrote:
> > On Thu, 2008-10-02 at 21:00 +0400, Vladislav Bolkhovitin wrote:
> >> Nicholas A. Bellinger wrote:
> >>>>> # Add some more HBA and storage Objects
> >>>>> target:~# mkdir -p $TARGET/fileio_0/file_object
> >>>>> target:~# mkdir -p $TARGET/rd_mcp_0/ramdisk0
> >>>>> target:~# mkdir -p $TARGET/rd_dr_0/ramdisk0
> >>>>>
> >>>>> target:~# mkdir -p $TARGET/pscsi_0/sdd
> >>>>> target:~# echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control
> >>>>> target:~# echo 1 > $TARGET/pscsi_0/sdd/dev_enable
> >>>>>
> >>>>> # Now, create LUN 1 and another Port Symlink to a new device on the same $IQN/tpgt_1
> >>>>> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> >>>>> # Create the iSCSI Target Port Mapping for $DEF_IN/tpgt_1 LUN 1
> >>>>> # to lvm_test0 and give it the port symbolic name of lio_east_port
> >>>>> ln -s $TARGET/pscsi_0/sdd/ "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
> >>>>>
> >>>>> target:~# tree $CONFIGFS
> >>>>> /sys/kernel/config/
> >>>>> `-- target
> >>>>> |-- core
> >>>>> | |-- fileio_0
> >>>>> | | |-- file_object
> >>>>> | | | |-- dev_control
> >>>>> | | | |-- dev_enable
> >>>>> | | | `-- dev_info
> >>>>> | | `-- hba_info
> >>>>> | |-- iblock_0
> >>>>> | | |-- hba_info
> >>>>> | | `-- lvm_test0
> >>>>> | | |-- dev_control
> >>>>> | | |-- dev_enable
> >>>>> | | `-- dev_info
> >>>>> | |-- pscsi_0
> >>>>> | | |-- hba_info
> >>>>> | | `-- sdd
> >>>>> | | |-- dev_control
> >>>>> | | |-- dev_enable
> >>>>> | | `-- dev_info
> >>>>> | |-- rd_dr_0
> >>>>> | | |-- hba_info
> >>>>> | | `-- ramdisk0
> >>>>> | | |-- dev_control
> >>>>> | | |-- dev_enable
> >>>>> | | `-- dev_info
> >>>>> | `-- rd_mcp_0
> >>>>> | |-- hba_info
> >>>>> | `-- ramdisk0
> >>>>> | |-- dev_control
> >>>>> | |-- dev_enable
> >>>>> | `-- dev_info
> >>>>> |-- iscsi
> >>>>> | |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> >>>>> | | `-- tpgt_1
> >>>>> | | |-- lun
> >>>>> | | | |-- lun_0
> >>>>> | | | | |-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> >>>>> | | | | |-- port_control
> >>>>> | | | | `-- port_info
> >>>>> | | | `-- lun_1
> >>>>> | | | |-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> >>>>> | | | |-- port_control
> >>>>> | | | `-- port_info
> >>>>> | | |-- np
> >>>>> | | | `-- 172.16.201.137:3260
> >>>>> | | | `-- portal_info
> >>>>> | | |-- tpg_control
> >>>>> | | `-- tpg_enable
> >>>>> | `-- lio_version
> >>>>> `-- version
> >>>>>
> >>>>> 22 directories, 29 files
> >>>> It's good, I like it. The only thing concerns me that, considering how
> >>>> much time *I* spent to understand it, for an average user understanding
> >>>> it can be an unbearable nightmare ;)
> >>>>
> >>> Well, the idea is not necessarily making the configfs interface the
> >>> easiest to use in the world by user directly through $CONFIGFS, but to
> >>> make the CLI scripts that speak $CONFIGFS/target CLI, and of course the
> >>> actual UIs for user that interact with generic target core and
> >>> $FABRIC_MODs be as simple and elegent as possible.
> >>>
> >>> That is what I believe the balance that a configfs enabled generic
> >>> target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD
> >>> maintainers looking to port their code to use a generic control
> >>> infrastructure. :-)
> >>>
> >>>> In a few days I'll write a proposed configfs hierarchy for existing SCST
> >>>> /proc interface.
> >>> Sounds good! Please let me know if you have questions.
> >> There's one unsolved problem. As I've already written, SCST core needs
> >> an ability to provide to user space a large amount of data, which may
> >> not fit to a single page.
> >>
> >> A list of connected initiators ("sessions"
> >> file in /proc), for instance. Each initiator in that list has a number
> >> of attributes: initiator name, target template name, count of
> >> outstanding commands, etc. The logical way for that would be to create a
> >> subdirectory for each initiator, like:
> >>
> >> /sys/kernel/config/
> >> `-- target
> >> `-- sessions
> >> `-- session1
> >> | |-- initiator_name
> >> | |-- template_name
> >> | `-- commands
> >> |
> >> `-- session2
> >> |-- initiator_name
> >> `-- template_name
> >> `-- commands
> >>
> >
> > The the Initiator Port ACLs need to go
> > under /sys/kernel/config/target/$FABRIC because the struct fabric_acl *
> > will always contain fabric dependent config items. For example, Since
> > these struct fabric_acl_t do *NOT* symlink directly back to
> > target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to
> > fabric_lun_t (iscsi_lun_t in my case) to Symlink to
> > a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with
> > the generic target configfs infrastructure.
> >
> > Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI
> > Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to
> > those Portal Groups. There are two cases:
> >
> > *) The production case with with user creating those ACLs under $FABRIC
> > (which is what I will focus on now).
> >
> > * And "Demo Mode" case where any Initiator logging into
> > $FABRIC/$ENDPOINT/$PORTAL can have access to all
> > $FABRIC/$ENDPOINT/lun/lun_*/*my_ports*
> >
> > The production ACL case would look like:
> >
> > export CONFIGFS=/sys/kernel/config/
> > export TARGET=/sys/kernel/config/target/core/
> > export FABRIC=/sys/kernel/config/target/iscsi/
> >
> > TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec
> > INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f
> >
> > <Setup $STORAGE_OBJECTs under $TARGET>
> >
> > # Create the LIO-target endpoint
> > mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260"
> > mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0"
> >
> > <Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0>
> >
> > # Create the Initiator ACL under $TARGET_IQN/tpgt_1
> > mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN"
> > # Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/
> > ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \
> > "$FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN/lun_0"
> >
> >>From there, you don't have to worry about PAGE_SIZE limitiations w/o, I
> > can simply use use:
> >
> > cat $FABRIC/iqn*/tpgt*/initiators/*/session
> >
> > to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target
> > Ports.
> >
> > Also I should add that I am currently using /proc/scsi_target/mib
> > and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko
> > and iscsi_target_mod.ko respectively. For the other "Demo Mode" case
> > mentioned above, I am currently using /proc/iscsi_target/mib/sess_attr
> > to see the active sessions for LIO-Target.
>
> Sorry for the delay. I didn't have a chance to look at it sufficiently
> close.
>
> Basically the idea about how to manage ACLs is good, but I don't like,
> that with it *ALL* the target drivers would have to implement the
> necessary code. It shouldn't be so, management of all security stuff
> should be purely duty of the mid-layer.
By the "mid-layer" I assume you mean the generic target mode engine, and
not the SCSI mid layer, yes..?
Point taken however that $TARGET_MOD could, and probably should have
some manner of generic ACL infrastructure available through FABRIC <->
TARGET API. I will have a look at scst_register() and
scst_register_session() and see where it should be adapted to
target_core_mod.
Btw, saying that "management of all security stuff should be purely duty
of the mid-layer" is incorrect however. The generic target engine needs
to make it *EASIER* for $FABRIC to allow those initiator ports access to
Mapped LUNs through fabric *DEPENDENT* endpoints, but trying to put all
fabric depepdent ACL endpoint logic in target_core_mod is IMHO a bad
idea.
Since each SCSI fabric's method of attaching SCSI LUN to Initiator Port
Endpoints in $FABRIC_MOD to SCSI Device (I have been calling
this /sys/kernel/config/target/core/$STORAGE_OBJECT for target_core_mod)
to create the SCSI Target Port is different. The reference I use for
iscsi_target_mod (and hence wrt target_core_mod) is proper T10/SCSI
terminlogy AFAIK. Lets reference the objects in
http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf
for the discussion so we can make sure we are on the same page..
For example, just because iSCSI uses TargetName + TargetPortalGroupTag
to attach target_core_mod's $STORAGE_OBJECTs at iSCSI Logical Units to,
does not mean that SAS, or another SCSI based target fabric know
anything about TargetName or TargetPortalGroupTag. In iSCSI, this is
defined in Section 2.1:
The I_T nexus can be identified by the conjunction of the SCSI port
names; that is, the I_T nexus identifier is the tuple (iSCSI
Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal
Group Tag).
Obviously the Initiator and Target Ports wrt iSCSI fabric are more
"symbolic" than devices attached to say a legacy Parallel SCSI bus
because of IP storage having multiple IP network portals across multiple
independent backbone providers and subnets (if you are using MC/S or
SCTP), etc, etc. This is this reason I think it does not make sense to
try to locate fabric dependent ACLs
under /sys/kernel/config/target/core/$STORAGE_OBJECT.
The type of things that need to be under $STORAGE_OBJECT, and that do
have a direct effect for $FABRIC mapped LUN endpoints are things like
device_type, max_sectors, sector_size, queue_depth and global READ-ONLY.
Of course, we want to be able to see *ALL* of
the /sys/kernel/config/target/$FABRIC dependent ACLs that have been
symlinked to said $STORAGE_OBJECT (this is one of the items on my list,
but not implemented in my current work).
> And this is exactly implemented
> in SCST. All what target drivers should do with it is to pass target's
> name on its registration in scst_register() and then while registering a
> session with remote initiator using scst_register_session() pass to it
> the initiator's name. Everything else is done by the SCST core.
>
At registration, I assume you mean admin wants to add an endpoint ACL
for a Initiator Port through $FABRIC/endpoint through $FABRIC_MOD..?
> Thus, I believe, all the ACL management should be done not in $FABRIC/,
> but in $TARGET/. It would remove all the corresponding configfs
> headaches from the target drivers writers.
>
I am not sure what "corresponding configfs headaches" you have in mind,
but please be specific and I will address them. :-)
> But, in fact, I asked about completely different thing. SCSI target
> mid-layer in some cases needs to export in user space amount of data,
> which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What
> should we do for it?
>
I did address point above in my work, and my commits
under /sys/kernel/config/target/iscsi implement how I get around the
PAGE_SIZE limitiations, which was something that I ran into (moving from
IOCTL and all, which requires overly complex kernel level information
code to get lots of output), to using ConfigFS, which has the same as
procfs and sysfs limits that you need to use seq_file() for > PAGE_SIZE.
Anyways, I did not end up using seq_file() for iscsi_target_mod current
configfs code, here is what I am using to address your above example wrt
getting all of session output:
>>From there, you don't have to worry about PAGE_SIZE limitiations w/o >
> > I can simply use use:
> >
> > cat $FABRIC/iqn*/tpgt*/initiators/*/session
> >
This ended up being `cat $FABRIC/iqn*/tpgt*/acls/*/info` to view all of
the active iSCSI Sessions on all iSCSI Target fabric endpoints..
The point is that regardless of kernel <-> user information output
method, it makes sense to break up large pieces of kernel level
information code and rely upon access through the VFS and cat to obtain
bulk output.
However, Joel has discussed removing the > PAGE_SIZE limitation for all
of the virtual filesystems, so I am sure he would be more than happy to
take a patch that addressed your concern if it is really that big of a
deal for the SCSI control path. With my current work with
target_core_mod and iscsi_target_mod wrt configfs I am not running into
this problem, so me producing this patch is not very high on my list..
> > I will be implementing this model over the next days.. I will post the
> > commit once its up and you can have a look..
> >
Ok, I ended up using a slightly different model for ACLs
under /sys/kernel/config/target/iscsi that the one I mentioned from last
week to get things up and running. I will be posting the commit and
info shortly.
Thanks for your comments Vlad!
--nab
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-07 20:50 ` Nicholas A. Bellinger
@ 2008-10-08 7:22 ` Nicholas A. Bellinger
2008-10-10 17:49 ` Vladislav Bolkhovitin
2008-10-10 17:48 ` Vladislav Bolkhovitin
1 sibling, 1 reply; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-08 7:22 UTC (permalink / raw)
To: Vladislav Bolkhovitin
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
On Tue, 2008-10-07 at 17:01 -0700, Nicholas A. Bellinger wrote:
<SNIP>
> > > The the Initiator Port ACLs need to go
> > > under /sys/kernel/config/target/$FABRIC because the struct fabric_acl *
> > > will always contain fabric dependent config items. For example, Since
> > > these struct fabric_acl_t do *NOT* symlink directly back to
> > > target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to
> > > fabric_lun_t (iscsi_lun_t in my case) to Symlink to
> > > a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with
> > > the generic target configfs infrastructure.
> > >
> > > Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI
> > > Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to
> > > those Portal Groups. There are two cases:
> > >
> > > *) The production case with with user creating those ACLs under $FABRIC
> > > (which is what I will focus on now).
> > >
> > > * And "Demo Mode" case where any Initiator logging into
> > > $FABRIC/$ENDPOINT/$PORTAL can have access to all
> > > $FABRIC/$ENDPOINT/lun/lun_*/*my_ports*
> > >
> > > The production ACL case would look like:
> > >
> > > export CONFIGFS=/sys/kernel/config/
> > > export TARGET=/sys/kernel/config/target/core/
> > > export FABRIC=/sys/kernel/config/target/iscsi/
> > >
> > > TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec
> > > INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f
> > >
> > > <Setup $STORAGE_OBJECTs under $TARGET>
> > >
> > > # Create the LIO-target endpoint
> > > mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260"
> > > mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0"
> > >
> > > <Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0>
> > >
> > > # Create the Initiator ACL under $TARGET_IQN/tpgt_1
> > > mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN"
> > > # Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/
> > > ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \
> > > "$FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN/lun_0"
> > >
> > >>From there, you don't have to worry about PAGE_SIZE limitiations w/o, I
> > > can simply use use:
> > >
> > > cat $FABRIC/iqn*/tpgt*/initiators/*/session
> > >
> > > to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target
> > > Ports.
> > >
> > > Also I should add that I am currently using /proc/scsi_target/mib
> > > and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko
> > > and iscsi_target_mod.ko respectively. For the other "Demo Mode" case
> > > mentioned above, I am currently using /proc/iscsi_target/mib/sess_attr
> > > to see the active sessions for LIO-Target.
> >
> > Sorry for the delay. I didn't have a chance to look at it sufficiently
> > close.
> >
> > Basically the idea about how to manage ACLs is good, but I don't like,
> > that with it *ALL* the target drivers would have to implement the
> > necessary code. It shouldn't be so, management of all security stuff
> > should be purely duty of the mid-layer.
>
> By the "mid-layer" I assume you mean the generic target mode engine, and
> not the SCSI mid layer, yes..?
>
> Point taken however that $TARGET_MOD could, and probably should have
> some manner of generic ACL infrastructure available through FABRIC <->
> TARGET API. I will have a look at scst_register() and
> scst_register_session() and see where it should be adapted to
> target_core_mod.
>
> Btw, saying that "management of all security stuff should be purely duty
> of the mid-layer" is incorrect however. The generic target engine needs
> to make it *EASIER* for $FABRIC to allow those initiator ports access to
> Mapped LUNs through fabric *DEPENDENT* endpoints, but trying to put all
> fabric depepdent ACL endpoint logic in target_core_mod is IMHO a bad
> idea.
>
> Since each SCSI fabric's method of attaching SCSI LUN to Initiator Port
> Endpoints in $FABRIC_MOD to SCSI Device (I have been calling
> this /sys/kernel/config/target/core/$STORAGE_OBJECT for target_core_mod)
> to create the SCSI Target Port is different. The reference I use for
> iscsi_target_mod (and hence wrt target_core_mod) is proper T10/SCSI
> terminlogy AFAIK. Lets reference the objects in
> http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf
> for the discussion so we can make sure we are on the same page..
>
> For example, just because iSCSI uses TargetName + TargetPortalGroupTag
> to attach target_core_mod's $STORAGE_OBJECTs at iSCSI Logical Units to,
> does not mean that SAS, or another SCSI based target fabric know
> anything about TargetName or TargetPortalGroupTag. In iSCSI, this is
> defined in Section 2.1:
>
> The I_T nexus can be identified by the conjunction of the SCSI port
> names; that is, the I_T nexus identifier is the tuple (iSCSI
> Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal
> Group Tag).
>
> Obviously the Initiator and Target Ports wrt iSCSI fabric are more
> "symbolic" than devices attached to say a legacy Parallel SCSI bus
> because of IP storage having multiple IP network portals across multiple
> independent backbone providers and subnets (if you are using MC/S or
> SCTP), etc, etc. This is this reason I think it does not make sense to
> try to locate fabric dependent ACLs
> under /sys/kernel/config/target/core/$STORAGE_OBJECT.
>
> The type of things that need to be under $STORAGE_OBJECT, and that do
> have a direct effect for $FABRIC mapped LUN endpoints are things like
> device_type, max_sectors, sector_size, queue_depth and global READ-ONLY.
> Of course, we want to be able to see *ALL* of
> the /sys/kernel/config/target/$FABRIC dependent ACLs that have been
> symlinked to said $STORAGE_OBJECT (this is one of the items on my list,
> but not implemented in my current work).
>
> > And this is exactly implemented
> > in SCST. All what target drivers should do with it is to pass target's
> > name on its registration in scst_register() and then while registering a
> > session with remote initiator using scst_register_session() pass to it
> > the initiator's name. Everything else is done by the SCST core.
> >
>
> At registration, I assume you mean admin wants to add an endpoint ACL
> for a Initiator Port through $FABRIC/endpoint through $FABRIC_MOD..?
>
> > Thus, I believe, all the ACL management should be done not in $FABRIC/,
> > but in $TARGET/. It would remove all the corresponding configfs
> > headaches from the target drivers writers.
> >
>
> I am not sure what "corresponding configfs headaches" you have in mind,
> but please be specific and I will address them. :-)
>
> > But, in fact, I asked about completely different thing. SCSI target
> > mid-layer in some cases needs to export in user space amount of data,
> > which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What
> > should we do for it?
> >
>
> I did address point above in my work, and my commits
> under /sys/kernel/config/target/iscsi implement how I get around the
> PAGE_SIZE limitiations, which was something that I ran into (moving from
> IOCTL and all, which requires overly complex kernel level information
> code to get lots of output), to using ConfigFS, which has the same as
> procfs and sysfs limits that you need to use seq_file() for > PAGE_SIZE.
> Anyways, I did not end up using seq_file() for iscsi_target_mod current
> configfs code, here is what I am using to address your above example wrt
> getting all of session output:
>
> >>From there, you don't have to worry about PAGE_SIZE limitiations w/o >
> > > I can simply use use:
> > >
> > > cat $FABRIC/iqn*/tpgt*/initiators/*/session
> > >
>
> This ended up being `cat $FABRIC/iqn*/tpgt*/acls/*/info` to view all of
> the active iSCSI Sessions on all iSCSI Target fabric endpoints..
>
> The point is that regardless of kernel <-> user information output
> method, it makes sense to break up large pieces of kernel level
> information code and rely upon access through the VFS and cat to obtain
> bulk output.
>
> However, Joel has discussed removing the > PAGE_SIZE limitation for all
> of the virtual filesystems, so I am sure he would be more than happy to
> take a patch that addressed your concern if it is really that big of a
> deal for the SCSI control path. With my current work with
> target_core_mod and iscsi_target_mod wrt configfs I am not running into
> this problem, so me producing this patch is not very high on my list..
>
> > > I will be implementing this model over the next days.. I will post the
> > > commit once its up and you can have a look..
> > >
>
> Ok, I ended up using a slightly different model for ACLs
> under /sys/kernel/config/target/iscsi that the one I mentioned from last
> week to get things up and running. I will be posting the commit and
> info shortly.
>
Ok, here is the commit:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commit;h=d1dc1c1da8375c1b9099166d7d93f7f45477f892
In the example I am using two iSCSI Initiators (one Debian and one
OpenSuse) that both have TPG LUN 0 and 1 mapped to their Initiator LUN 0
and 1 under $FABRIC/$IQN/tpgt_1.
Here is what it looks like from the CLI:
export TARGET=/sys/kernel/config/target/core/
export FABRIC=/sys/kernel/config/target/iscsi/
<Setup target_core_mod storage objects..>
DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
# The first mkdir(2) to $FABRIC will load iscsi_target_mod
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
# Create TPG LUN 0 and symlink $STORAGE_OBJECT from target_core_mod
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port"
# Create TPG LUN 1 and symlink $STORAGE_OBJECT from target_core_mod
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
ln -s $TARGET/pscsi_0/sdd "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
INITIATOR_DEBIAN="iqn.1993-08.org.debian:01:2dadf92d0ef"
# Create Node and two LUN ACL Symlinks for Debian Initiator
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0"
ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0/."
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_1"
ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_1/."
INITIATOR_SUSE="iqn.1996-04.de.suse:01:1661f9ee7b5"
# Create Node and two LUN ACL Symlinks for Suse Initiator
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_0"
ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_0/."
mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_1"
ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_1/."
# Enable the $FABRIC endpoint so it can accept new iSCSI sessions.
echo 1 > $FABRIC/$DEF_IQN/tpgt_1/enable
And running....
target:/sys/kernel/config# tree $FABRIC
/sys/kernel/config/target/iscsi/
|-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
| `-- tpgt_1
| |-- acls
| | |-- iqn.1993-08.org.debian:01:2dadf92d0ef
| | | |-- control
| | | |-- info
| | | |-- lun_0
| | | | `-- lun_0 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_0
| | | `-- lun_1
| | | `-- lun_1 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_1
| | `-- iqn.1996-04.de.suse:01:1661f9ee7b5
| | |-- control
| | |-- info
| | |-- lun_0
| | | `-- lun_0 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_0
| | `-- lun_1
| | `-- lun_1 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_1
| |-- control
| |-- enable
| |-- lun
| | |-- lun_0
| | | |-- control
| | | |-- info
| | | `-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
| | `-- lun_1
| | |-- control
| | |-- info
| | `-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
| `-- np
| `-- 172.16.201.137:3260
| `-- portal_info
`-- lio_version
20 directories, 12 files
Note that iSCSI Initiator LUN ACL Symlinks are done on a per TPGT
context and are only allowed for TPG LUNs under the same
$FABRIC/$IQN/$TPGT path.
--------------------------------------------------------------------------------
Dump information for all running iSCSI Sessons on all iSCSI Target
endpoints..:
target:/sys/kernel/config# cat $FABRIC/iqn*/tpgt*/acls/*/info
InitiatorName: iqn.1993-08.org.debian:01:2dadf92d0ef
InitiatorAlias: ubuntu
LIO Session ID: 2 ISID: 0x00 02 3d 05 00 00 TSIH: 2 SessionType: Normal
Cmds in Session Pool: 1 Session State: TARG_SESS_STATE_LOGGED_IN
---------------------[iSCSI Session Values]-----------------------
CmdSN/WR : CmdSN/WC : ExpCmdSN : MaxCmdSN : ITT : TTT
0x00000010 0x00000010 0x00000042 0x00000051 0x090a0040 0x000000e7
----------------------[iSCSI Connections]-------------------------
CID: 0 Connection State: TARG_CONN_STATE_LOGGED_IN
Address 172.16.201.129 TCP StatSN: 0x0000006c
InitiatorName: iqn.1996-04.de.suse:01:1661f9ee7b5
InitiatorAlias: opensuse
LIO Session ID: 13 ISID: 0x00 02 3d 01 00 00 TSIH: 13 SessionType: Normal
Cmds in Session Pool: 1 Session State: TARG_SESS_STATE_LOGGED_IN
---------------------[iSCSI Session Values]-----------------------
CmdSN/WR : CmdSN/WC : ExpCmdSN : MaxCmdSN : ITT : TTT
0x00000010 0x00000010 0x00000022 0x00000031 0x040a0000 0x00000003
----------------------[iSCSI Connections]-------------------------
CID: 0 Connection State: TARG_CONN_STATE_LOGGED_IN
Address 172.16.201.136 TCP StatSN: 0x00000003
Anyways, you get the idea. The primary functionality is up for getting
ACLs iSCSI Initiator Nodes and LUNs symlinked to TPG LUNs symlinked to
$STORAGE_OBJECTs from target_core_mod. I will be continuing to convert
stuff from the IOCTL, mostly things that need to be made into configfs
attributes. I am going to focus on the getting the remaining stuff
under configfs up for iscsi_target_mod, and start looking at the much
larger todo item of seeing how we can merge target_core_mod and scst
core.. Please have a look and let me know what you think (espically the
target_core_mod parts), and I will pull the latest SCST code and start
looking at the FABRIC <-> TARGET you mentioned..
--nab
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-07 20:50 ` Nicholas A. Bellinger
2008-10-08 7:22 ` Nicholas A. Bellinger
@ 2008-10-10 17:48 ` Vladislav Bolkhovitin
2008-10-10 20:41 ` Nicholas A. Bellinger
1 sibling, 1 reply; 15+ messages in thread
From: Vladislav Bolkhovitin @ 2008-10-10 17:48 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
Nicholas A. Bellinger wrote:
>>> Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI
>>> Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to
>>> those Portal Groups. There are two cases:
>>>
>>> *) The production case with with user creating those ACLs under $FABRIC
>>> (which is what I will focus on now).
>>>
>>> * And "Demo Mode" case where any Initiator logging into
>>> $FABRIC/$ENDPOINT/$PORTAL can have access to all
>>> $FABRIC/$ENDPOINT/lun/lun_*/*my_ports*
>>>
>>> The production ACL case would look like:
>>>
>>> export CONFIGFS=/sys/kernel/config/
>>> export TARGET=/sys/kernel/config/target/core/
>>> export FABRIC=/sys/kernel/config/target/iscsi/
>>>
>>> TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec
>>> INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f
>>>
>>> <Setup $STORAGE_OBJECTs under $TARGET>
>>>
>>> # Create the LIO-target endpoint
>>> mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260"
>>> mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0"
>>>
>>> <Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0>
>>>
>>> # Create the Initiator ACL under $TARGET_IQN/tpgt_1
>>> mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN"
>>> # Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/
>>> ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \
>>> "$FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN/lun_0"
>>>
>>> >From there, you don't have to worry about PAGE_SIZE limitiations w/o, I
>>> can simply use use:
>>>
>>> cat $FABRIC/iqn*/tpgt*/initiators/*/session
>>>
>>> to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target
>>> Ports.
>>>
>>> Also I should add that I am currently using /proc/scsi_target/mib
>>> and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko
>>> and iscsi_target_mod.ko respectively. For the other "Demo Mode" case
>>> mentioned above, I am currently using /proc/iscsi_target/mib/sess_attr
>>> to see the active sessions for LIO-Target.
>> Sorry for the delay. I didn't have a chance to look at it sufficiently
>> close.
>>
>> Basically the idea about how to manage ACLs is good, but I don't like,
>> that with it *ALL* the target drivers would have to implement the
>> necessary code. It shouldn't be so, management of all security stuff
>> should be purely duty of the mid-layer.
>
> By the "mid-layer" I assume you mean the generic target mode engine, and
> not the SCSI mid layer, yes..?
Yes, sure
> Point taken however that $TARGET_MOD could, and probably should have
> some manner of generic ACL infrastructure available through FABRIC <->
> TARGET API. I will have a look at scst_register() and
> scst_register_session() and see where it should be adapted to
> target_core_mod.
>
> Btw, saying that "management of all security stuff should be purely duty
> of the mid-layer" is incorrect however. The generic target engine needs
> to make it *EASIER* for $FABRIC to allow those initiator ports access to
> Mapped LUNs through fabric *DEPENDENT* endpoints, but trying to put all
> fabric depepdent ACL endpoint logic in target_core_mod is IMHO a bad
> idea.
>
> Since each SCSI fabric's method of attaching SCSI LUN to Initiator Port
> Endpoints in $FABRIC_MOD to SCSI Device (I have been calling
> this /sys/kernel/config/target/core/$STORAGE_OBJECT for target_core_mod)
> to create the SCSI Target Port is different. The reference I use for
> iscsi_target_mod (and hence wrt target_core_mod) is proper T10/SCSI
> terminlogy AFAIK. Lets reference the objects in
> http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf
> for the discussion so we can make sure we are on the same page..
>
> For example, just because iSCSI uses TargetName + TargetPortalGroupTag
> to attach target_core_mod's $STORAGE_OBJECTs at iSCSI Logical Units to,
> does not mean that SAS, or another SCSI based target fabric know
> anything about TargetName or TargetPortalGroupTag. In iSCSI, this is
> defined in Section 2.1:
>
> The I_T nexus can be identified by the conjunction of the SCSI port
> names; that is, the I_T nexus identifier is the tuple (iSCSI
> Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal
> Group Tag).
>
> Obviously the Initiator and Target Ports wrt iSCSI fabric are more
> "symbolic" than devices attached to say a legacy Parallel SCSI bus
> because of IP storage having multiple IP network portals across multiple
> independent backbone providers and subnets (if you are using MC/S or
> SCTP), etc, etc. This is this reason I think it does not make sense to
> try to locate fabric dependent ACLs
> under /sys/kernel/config/target/core/$STORAGE_OBJECT.
>
> The type of things that need to be under $STORAGE_OBJECT, and that do
> have a direct effect for $FABRIC mapped LUN endpoints are things like
> device_type, max_sectors, sector_size, queue_depth and global READ-ONLY.
> Of course, we want to be able to see *ALL* of
> the /sys/kernel/config/target/$FABRIC dependent ACLs that have been
> symlinked to said $STORAGE_OBJECT (this is one of the items on my list,
> but not implemented in my current work).
Nicholas, you think too iSCSI centric. From access control POV only 2
thing matter:
1. Target name - to assign to it a default access control group (ACL, if
you like that name), i.e. an ACL for initiators not listed in other ACLs
2. Initiator name - to assign it to the corresponding ACL.
It doesn't matter if those names are IQNs for iSCSI or WWNs for FC, or
bus:id:lun for parallel SCSI.
For example, consider target "TTT", which has 2 ACLs: "Default" with
Device1 as LUN 0 and "Group1" with "Device2" as LUN 0. "Group1"
specified for initiator "III1". Then when initiator "III1" connected to
target "TTT", it would be assigned to "Group1" and see "Device2". If
then initiator "III2" connected, it would be assigned to "Default" ACL
and see "Device1". "Default" group can be empty, if necessary. There's
nothing transport specific in this approach at all.
I strongly suggest you to look at SCST access control approach and make
sure you understand it before reply. It would save us a lot of time and
effort. Note, this approach isn't something theoretical. It's proved by
4 years of successful usage.
Also, it would be good, if you shift your terminology to be less iSCSI
specific and use the corresponding terms from SAM, where possible. We
are discussing a config interface for a generic target engine, aren't
we? Otherwise sometimes it's quite hard for me to understand you and I
have strong suspicions that other people are getting or already got lost
in it.
>> Thus, I believe, all the ACL management should be done not in $FABRIC/,
>> but in $TARGET/. It would remove all the corresponding configfs
>> headaches from the target drivers writers.
>>
>
> I am not sure what "corresponding configfs headaches" you have in mind,
> but please be specific and I will address them. :-)
Creating and managing the necessary configfs entries.
>> But, in fact, I asked about completely different thing. SCSI target
>> mid-layer in some cases needs to export in user space amount of data,
>> which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What
>> should we do for it?
>>
>
> I did address point above in my work, and my commits
> under /sys/kernel/config/target/iscsi implement how I get around the
> PAGE_SIZE limitiations, which was something that I ran into (moving from
> IOCTL and all, which requires overly complex kernel level information
> code to get lots of output), to using ConfigFS, which has the same as
> procfs and sysfs limits that you need to use seq_file() for > PAGE_SIZE.
> Anyways, I did not end up using seq_file() for iscsi_target_mod current
> configfs code, here is what I am using to address your above example wrt
> getting all of session output:
Hmm, I looked at the code and in lio_target_initiator_nacl_info() saw
something like:
rb += sprintf(page+rb, "LIO Session ID: %u "
"ISID: 0x%02x %02x %02x %02x %02x %02x "
"TSIH: %hu ", sess->sid,
sess->isid[0], sess->isid[1], sess->isid[2],
sess->isid[3], sess->isid[4], sess->isid[5],
sess->tsih);
rb += sprintf(page+rb, "SessionType: %s\n",
(SESS_OPS(sess)->SessionType) ?
"Discovery" : "Normal");
rb += sprintf(page+rb, "Cmds in Session Pool: %d ",
atomic_read(&sess->pool_count));
rb += sprintf(page+rb, "Session State: ");
It doesn't look for me like it addresses the PAGE_SIZE limitation issue.
>> >From there, you don't have to worry about PAGE_SIZE limitiations w/o >
>>> I can simply use use:
>>>
>>> cat $FABRIC/iqn*/tpgt*/initiators/*/session
>>>
>
> This ended up being `cat $FABRIC/iqn*/tpgt*/acls/*/info` to view all of
> the active iSCSI Sessions on all iSCSI Target fabric endpoints..
>
> The point is that regardless of kernel <-> user information output
> method, it makes sense to break up large pieces of kernel level
> information code and rely upon access through the VFS and cat to obtain
> bulk output.
>
> However, Joel has discussed removing the > PAGE_SIZE limitation for all
> of the virtual filesystems, so I am sure he would be more than happy to
> take a patch that addressed your concern if it is really that big of a
> deal for the SCSI control path. With my current work with
> target_core_mod and iscsi_target_mod wrt configfs I am not running into
> this problem, so me producing this patch is not very high on my list..
>
>>> I will be implementing this model over the next days.. I will post the
>>> commit once its up and you can have a look..
>>>
>
> Ok, I ended up using a slightly different model for ACLs
> under /sys/kernel/config/target/iscsi that the one I mentioned from last
> week to get things up and running. I will be posting the commit and
> info shortly.
>
> Thanks for your comments Vlad!
>
> --nab
>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-08 7:22 ` Nicholas A. Bellinger
@ 2008-10-10 17:49 ` Vladislav Bolkhovitin
0 siblings, 0 replies; 15+ messages in thread
From: Vladislav Bolkhovitin @ 2008-10-10 17:49 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-iscsi-target-dev, FUJITA Tomonori, Mike Christie,
linux-scsi, iet-dev, Greg KH, Jerome Martin, LKML,
James Bottomley, SCST-Devel, Joel Becker, H. Peter Anvin
Nicholas A. Bellinger wrote:
> Ok, here is the commit:
>
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commit;h=d1dc1c1da8375c1b9099166d7d93f7f45477f892
>
> In the example I am using two iSCSI Initiators (one Debian and one
> OpenSuse) that both have TPG LUN 0 and 1 mapped to their Initiator LUN 0
> and 1 under $FABRIC/$IQN/tpgt_1.
>
> Here is what it looks like from the CLI:
>
> export TARGET=/sys/kernel/config/target/core/
> export FABRIC=/sys/kernel/config/target/iscsi/
>
> <Setup target_core_mod storage objects..>
>
> DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0"
>
> # The first mkdir(2) to $FABRIC will load iscsi_target_mod
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
> # Create TPG LUN 0 and symlink $STORAGE_OBJECT from target_core_mod
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
> ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port"
> # Create TPG LUN 1 and symlink $STORAGE_OBJECT from target_core_mod
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1"
> ln -s $TARGET/pscsi_0/sdd "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port"
>
> INITIATOR_DEBIAN="iqn.1993-08.org.debian:01:2dadf92d0ef"
>
> # Create Node and two LUN ACL Symlinks for Debian Initiator
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0"
> ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0/."
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_1"
> ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_1/."
>
> INITIATOR_SUSE="iqn.1996-04.de.suse:01:1661f9ee7b5"
>
> # Create Node and two LUN ACL Symlinks for Suse Initiator
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_0"
> ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_0/."
> mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_1"
> ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_1/."
>
> # Enable the $FABRIC endpoint so it can accept new iSCSI sessions.
> echo 1 > $FABRIC/$DEF_IQN/tpgt_1/enable
>
>
> And running....
>
>
> target:/sys/kernel/config# tree $FABRIC
> /sys/kernel/config/target/iscsi/
> |-- iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0
> | `-- tpgt_1
> | |-- acls
> | | |-- iqn.1993-08.org.debian:01:2dadf92d0ef
> | | | |-- control
> | | | |-- info
> | | | |-- lun_0
> | | | | `-- lun_0 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_0
> | | | `-- lun_1
> | | | `-- lun_1 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_1
> | | `-- iqn.1996-04.de.suse:01:1661f9ee7b5
> | | |-- control
> | | |-- info
> | | |-- lun_0
> | | | `-- lun_0 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_0
> | | `-- lun_1
> | | `-- lun_1 -> ../../../../../../../target/iscsi/iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0/tpgt_1/lun/lun_1
> | |-- control
> | |-- enable
> | |-- lun
> | | |-- lun_0
> | | | |-- control
> | | | |-- info
> | | | `-- lio_west_port -> ../../../../../../target/core/iblock_0/lvm_test0
> | | `-- lun_1
> | | |-- control
> | | |-- info
> | | `-- lio_east_port -> ../../../../../../target/core/pscsi_0/sdd
> | `-- np
> | `-- 172.16.201.137:3260
> | `-- portal_info
> `-- lio_version
>
> 20 directories, 12 files
>
> Note that iSCSI Initiator LUN ACL Symlinks are done on a per TPGT
> context and are only allowed for TPG LUNs under the same
> $FABRIC/$IQN/$TPGT path.
I don't like that limitation. It looks completely artificial for me. And
this approach doesn't address what to do if there is a connection from
initiator, for which there is no corresponding ACL entry.
I again strongly suggest you to get familiar with SCST access control
approach before making the next move. It's proved to be good and we
should take all the best from it.
> --------------------------------------------------------------------------------
>
> Dump information for all running iSCSI Sessons on all iSCSI Target
> endpoints..:
>
> target:/sys/kernel/config# cat $FABRIC/iqn*/tpgt*/acls/*/info
>
> InitiatorName: iqn.1993-08.org.debian:01:2dadf92d0ef
> InitiatorAlias: ubuntu
> LIO Session ID: 2 ISID: 0x00 02 3d 05 00 00 TSIH: 2 SessionType: Normal
> Cmds in Session Pool: 1 Session State: TARG_SESS_STATE_LOGGED_IN
> ---------------------[iSCSI Session Values]-----------------------
> CmdSN/WR : CmdSN/WC : ExpCmdSN : MaxCmdSN : ITT : TTT
> 0x00000010 0x00000010 0x00000042 0x00000051 0x090a0040 0x000000e7
> ----------------------[iSCSI Connections]-------------------------
> CID: 0 Connection State: TARG_CONN_STATE_LOGGED_IN
> Address 172.16.201.129 TCP StatSN: 0x0000006c
> InitiatorName: iqn.1996-04.de.suse:01:1661f9ee7b5
> InitiatorAlias: opensuse
> LIO Session ID: 13 ISID: 0x00 02 3d 01 00 00 TSIH: 13 SessionType: Normal
> Cmds in Session Pool: 1 Session State: TARG_SESS_STATE_LOGGED_IN
> ---------------------[iSCSI Session Values]-----------------------
> CmdSN/WR : CmdSN/WC : ExpCmdSN : MaxCmdSN : ITT : TTT
> 0x00000010 0x00000010 0x00000022 0x00000031 0x040a0000 0x00000003
> ----------------------[iSCSI Connections]-------------------------
> CID: 0 Connection State: TARG_CONN_STATE_LOGGED_IN
> Address 172.16.201.136 TCP StatSN: 0x00000003
>
>
> Anyways, you get the idea. The primary functionality is up for getting
> ACLs iSCSI Initiator Nodes and LUNs symlinked to TPG LUNs symlinked to
> $STORAGE_OBJECTs from target_core_mod. I will be continuing to convert
> stuff from the IOCTL, mostly things that need to be made into configfs
> attributes. I am going to focus on the getting the remaining stuff
> under configfs up for iscsi_target_mod, and start looking at the much
> larger todo item of seeing how we can merge target_core_mod and scst
> core.. Please have a look and let me know what you think (espically the
> target_core_mod parts), and I will pull the latest SCST code and start
> looking at the FABRIC <-> TARGET you mentioned..
>
> --nab
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-10 17:48 ` Vladislav Bolkhovitin
@ 2008-10-10 20:41 ` Nicholas A. Bellinger
2008-10-21 18:11 ` Vladislav Bolkhovitin
0 siblings, 1 reply; 15+ messages in thread
From: Nicholas A. Bellinger @ 2008-10-10 20:41 UTC (permalink / raw)
To: linux-iscsi-target-dev
Cc: FUJITA Tomonori, Mike Christie, linux-scsi, iet-dev, Greg KH,
Jerome Martin, LKML, James Bottomley, SCST-Devel, Joel Becker,
H. Peter Anvin
On Fri, 2008-10-10 at 21:48 +0400, Vladislav Bolkhovitin wrote:
> > Point taken however that $TARGET_MOD could, and probably should have
> > some manner of generic ACL infrastructure available through FABRIC <->
> > TARGET API. I will have a look at scst_register() and
> > scst_register_session() and see where it should be adapted to
> > target_core_mod.
> >
> > Btw, saying that "management of all security stuff should be purely duty
> > of the mid-layer" is incorrect however. The generic target engine needs
> > to make it *EASIER* for $FABRIC to allow those initiator ports access to
> > Mapped LUNs through fabric *DEPENDENT* endpoints, but trying to put all
> > fabric depepdent ACL endpoint logic in target_core_mod is IMHO a bad
> > idea.
> >
> > Since each SCSI fabric's method of attaching SCSI LUN to Initiator Port
> > Endpoints in $FABRIC_MOD to SCSI Device (I have been calling
> > this /sys/kernel/config/target/core/$STORAGE_OBJECT for target_core_mod)
> > to create the SCSI Target Port is different. The reference I use for
> > iscsi_target_mod (and hence wrt target_core_mod) is proper T10/SCSI
> > terminlogy AFAIK. Lets reference the objects in
> > http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf
> > for the discussion so we can make sure we are on the same page..
> >
> > For example, just because iSCSI uses TargetName + TargetPortalGroupTag
> > to attach target_core_mod's $STORAGE_OBJECTs at iSCSI Logical Units to,
> > does not mean that SAS, or another SCSI based target fabric know
> > anything about TargetName or TargetPortalGroupTag. In iSCSI, this is
> > defined in Section 2.1:
> >
> > The I_T nexus can be identified by the conjunction of the SCSI port
> > names; that is, the I_T nexus identifier is the tuple (iSCSI
> > Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal
> > Group Tag).
> >
> > Obviously the Initiator and Target Ports wrt iSCSI fabric are more
> > "symbolic" than devices attached to say a legacy Parallel SCSI bus
> > because of IP storage having multiple IP network portals across multiple
> > independent backbone providers and subnets (if you are using MC/S or
> > SCTP), etc, etc. This is this reason I think it does not make sense to
> > try to locate fabric dependent ACLs
> > under /sys/kernel/config/target/core/$STORAGE_OBJECT.
> >
> > The type of things that need to be under $STORAGE_OBJECT, and that do
> > have a direct effect for $FABRIC mapped LUN endpoints are things like
> > device_type, max_sectors, sector_size, queue_depth and global READ-ONLY.
> > Of course, we want to be able to see *ALL* of
> > the /sys/kernel/config/target/$FABRIC dependent ACLs that have been
> > symlinked to said $STORAGE_OBJECT (this is one of the items on my list,
> > but not implemented in my current work).
>
> Nicholas, you think too iSCSI centric. From access control POV only 2
> thing matter:
>
Not true. Thre is *NOTHING* in target_core_mod's configfs layout that
is "iSCSI centric", or $FABRIC centric at all. We are talking about
configfs symbolic links with /bin/ls from target_core_mod storage
objects and $FABRIC_MOD portal group ports for $FABRIC LUNs. How
Initiators logging into those $FABRIC_MOD endpoints (Node ACLs) and
accessing those $FABRIC LUNs (LUN ACLs) is still $FABRIC dependent.
There is nothing iSCSI, SCSI, ATA or NBD centric about it, it is UNIX
centric and works generically across any fabric, that is the whole point
of having target_core_mod. Why would we want to limit the generic
target engine to having Parallel SCSI (see below) centric ACLs..?
>
> 1. Target name - to assign to it a default access control group (ACL, if
> you like that name), i.e. an ACL for initiators not listed in other ACLs
>
Wrong. For iSCSI, Section 2.1 of RFC-3720 defines it as TargetName +
TargetPortalGroupTag, and this is the method that all of my upstream
work and any proper implemention of target node endpoint and target
portal group assignement.
> 2. Initiator name - to assign it to the corresponding ACL.
>
> It doesn't matter if those names are IQNs for iSCSI or WWNs for FC, or
> bus:id:lun for parallel SCSI.
>
> For example, consider target "TTT", which has 2 ACLs: "Default" with
> Device1 as LUN 0 and "Group1" with "Device2" as LUN 0. "Group1"
> specified for initiator "III1". Then when initiator "III1" connected to
> target "TTT", it would be assigned to "Group1" and see "Device2". If
> then initiator "III2" connected, it would be assigned to "Default" ACL
> and see "Device1". "Default" group can be empty, if necessary. There's
> nothing transport specific in this approach at all.
>
Your example limits all iSCSI ACLs to TargetName, instead of TargetName
+TargetPortalGroupTag.
That is why everything related to iscsi_target_mod operation is
below /sys/kernel/config/target/iscsi/$IQN/$TPGT and
not /sys/kernel/config/target/iscsi/$IQN.
Obviously I am not going to limit my upstream iscsi_target_mod to an ACL
structure that does not take into account a complete RFC-3720
implementation, but I would be more than happy to see you update your
ACL code to reflect proper TargetName+TargetPortalGroupTag that RFC-3720
lays out for the iSCSI Target Port <-> SCSI Target Port mapping.
> I strongly suggest you to look at SCST access control approach and make
> sure you understand it before reply. It would save us a lot of time and
> effort. Note, this approach isn't something theoretical. It's proved by
> 4 years of successful usage.
I don't really care about history, I care about code. Why don't you
start breaking out which code you want to go upstream so that it makes
my job easier or start integrating your own ACL control model into
drivers/lio-core/target_core_configfs.c and post a patch and then we can
discuss!
In all honesty however, the ACL code is a small nit-pick compared to how
we are going to merge your $FABRIC <-> $TARGET API with
drivers/lio-core. Why don't you start there first while I consider what
can be made generic for ACL code for the target_core_mod configfs
upstream work.
> Also, it would be good, if you shift your terminology to be less iSCSI
> specific and use the corresponding terms from SAM, where possible. We
> are discussing a config interface for a generic target engine, aren't
> we? Otherwise sometimes it's quite hard for me to understand you and I
> have strong suspicions that other people are getting or already got lost
> in it.
>
Heh, why do you think I moved my upstream work to ConfigFS..? Being
able to use two 'mkdir -p' and two 'ln -s' to create two iSCSI Initiator
Node ACLs and four iSCSI Initiator Node ACLs is as easy as it gets!?
Being able to call a *SINGLE* mkdir -p to create Network Portal on an
iSCSI Target Portal Group, and from an unloaded iscsi_target_mod preform
four different iSCSI target mod ops is a simple as it gets
target_core_mod is a generic target engine that uses the most advanced
and complete iscsi_target_mod, so one must put effort into understanding
the drivers/lio-core/*configfs* to understand the simplicity of the
code.
> >> Thus, I believe, all the ACL management should be done not in $FABRIC/,
> >> but in $TARGET/. It would remove all the corresponding configfs
> >> headaches from the target drivers writers.
> >>
> >
> >
> >> But, in fact, I asked about completely different thing. SCSI target
> >> mid-layer in some cases needs to export in user space amount of data,
> >> which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What
> >> should we do for it?
> >>
> >
> > I did address point above in my work, and my commits
> > under /sys/kernel/config/target/iscsi implement how I get around the
> > PAGE_SIZE limitiations, which was something that I ran into (moving from
> > IOCTL and all, which requires overly complex kernel level information
> > code to get lots of output), to using ConfigFS, which has the same as
> > procfs and sysfs limits that you need to use seq_file() for > PAGE_SIZE.
> > Anyways, I did not end up using seq_file() for iscsi_target_mod current
> > configfs code, here is what I am using to address your above example wrt
> > getting all of session output:
>
> Hmm, I looked at the code and in lio_target_initiator_nacl_info() saw
> something like:
>
> rb += sprintf(page+rb, "LIO Session ID: %u "
> "ISID: 0x%02x %02x %02x %02x %02x %02x "
> "TSIH: %hu ", sess->sid,
> sess->isid[0], sess->isid[1], sess->isid[2],
> sess->isid[3], sess->isid[4], sess->isid[5],
> sess->tsih);
> rb += sprintf(page+rb, "SessionType: %s\n",
> (SESS_OPS(sess)->SessionType) ?
> "Discovery" : "Normal");
> rb += sprintf(page+rb, "Cmds in Session Pool: %d ",
> atomic_read(&sess->pool_count));
> rb += sprintf(page+rb, "Session State: ");
>
> It doesn't look for me like it addresses the PAGE_SIZE limitation issue.
>
You are still completely missing the point here.. Because I broke out
my projects *LEGACY* information code (just like every other upstream
project is required to do) I do not have gigantic nested loops in my
target_core_mod and iscsi_target_mod code that can only dump output
using seq_file() out of procfs or through god awful IOCTL code.
Every other upstream project that *HAS* broken out its legacy
informational code into sysfs (which again, has the same limitiation) or
another sane virtual FS control interface (like configfs) is working
just fine. Sysfs is used by people on many many millions of Linux
boxes, and all existing upstream projects that use sysfs have no problem
getting lots and lots and lots of info using /bin/cat even with the
PAGE_SIZE limitiation in place.
So this means you have two choices:
*) Fix your legacy code to use a sane informational output interface for
your upstream branch.
*) Produce a patch to solve the limitiation and produce an API and post
it to linuxfs-devel.
Again, for my upstream work with iscsi_target_mod, everyone will just be
using '/bin/cat' and wildcards (*) to grok the thousands
of /sys/kernel/config/target/iscsi/$IQNs configfs objects running on the
production systems. Because of this reason, I am not pained by this
limitiation (as some of your code appears to be) so please don't expect
me to produce this patch.
--nab
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
2008-10-10 20:41 ` Nicholas A. Bellinger
@ 2008-10-21 18:11 ` Vladislav Bolkhovitin
0 siblings, 0 replies; 15+ messages in thread
From: Vladislav Bolkhovitin @ 2008-10-21 18:11 UTC (permalink / raw)
To: linux-iscsi-target-dev
Cc: FUJITA Tomonori, Mike Christie, linux-scsi, Greg KH,
Jerome Martin, LKML, James Bottomley, SCST-Devel, Joel Becker,
H. Peter Anvin
Nicholas A. Bellinger wrote:
> On Fri, 2008-10-10 at 21:48 +0400, Vladislav Bolkhovitin wrote:
>>> Point taken however that $TARGET_MOD could, and probably should have
>>> some manner of generic ACL infrastructure available through FABRIC <->
>>> TARGET API. I will have a look at scst_register() and
>>> scst_register_session() and see where it should be adapted to
>>> target_core_mod.
>>>
>>> Btw, saying that "management of all security stuff should be purely duty
>>> of the mid-layer" is incorrect however. The generic target engine needs
>>> to make it *EASIER* for $FABRIC to allow those initiator ports access to
>>> Mapped LUNs through fabric *DEPENDENT* endpoints, but trying to put all
>>> fabric depepdent ACL endpoint logic in target_core_mod is IMHO a bad
>>> idea.
>>>
>>> Since each SCSI fabric's method of attaching SCSI LUN to Initiator Port
>>> Endpoints in $FABRIC_MOD to SCSI Device (I have been calling
>>> this /sys/kernel/config/target/core/$STORAGE_OBJECT for target_core_mod)
>>> to create the SCSI Target Port is different. The reference I use for
>>> iscsi_target_mod (and hence wrt target_core_mod) is proper T10/SCSI
>>> terminlogy AFAIK. Lets reference the objects in
>>> http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf
>>> for the discussion so we can make sure we are on the same page..
>>>
>>> For example, just because iSCSI uses TargetName + TargetPortalGroupTag
>>> to attach target_core_mod's $STORAGE_OBJECTs at iSCSI Logical Units to,
>>> does not mean that SAS, or another SCSI based target fabric know
>>> anything about TargetName or TargetPortalGroupTag. In iSCSI, this is
>>> defined in Section 2.1:
>>>
>>> The I_T nexus can be identified by the conjunction of the SCSI port
>>> names; that is, the I_T nexus identifier is the tuple (iSCSI
>>> Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal
>>> Group Tag).
>>>
>>> Obviously the Initiator and Target Ports wrt iSCSI fabric are more
>>> "symbolic" than devices attached to say a legacy Parallel SCSI bus
>>> because of IP storage having multiple IP network portals across multiple
>>> independent backbone providers and subnets (if you are using MC/S or
>>> SCTP), etc, etc. This is this reason I think it does not make sense to
>>> try to locate fabric dependent ACLs
>>> under /sys/kernel/config/target/core/$STORAGE_OBJECT.
>>>
>>> The type of things that need to be under $STORAGE_OBJECT, and that do
>>> have a direct effect for $FABRIC mapped LUN endpoints are things like
>>> device_type, max_sectors, sector_size, queue_depth and global READ-ONLY.
>>> Of course, we want to be able to see *ALL* of
>>> the /sys/kernel/config/target/$FABRIC dependent ACLs that have been
>>> symlinked to said $STORAGE_OBJECT (this is one of the items on my list,
>>> but not implemented in my current work).
>> Nicholas, you think too iSCSI centric. From access control POV only 2
>> thing matter:
>>
>
> Not true. Thre is *NOTHING* in target_core_mod's configfs layout that
> is "iSCSI centric", or $FABRIC centric at all. We are talking about
> configfs symbolic links with /bin/ls from target_core_mod storage
> objects and $FABRIC_MOD portal group ports for $FABRIC LUNs. How
> Initiators logging into those $FABRIC_MOD endpoints (Node ACLs) and
> accessing those $FABRIC LUNs (LUN ACLs) is still $FABRIC dependent.
>
> There is nothing iSCSI, SCSI, ATA or NBD centric about it, it is UNIX
> centric and works generically across any fabric, that is the whole point
> of having target_core_mod. Why would we want to limit the generic
> target engine to having Parallel SCSI (see below) centric ACLs..?
>
>> 1. Target name - to assign to it a default access control group (ACL, if
>> you like that name), i.e. an ACL for initiators not listed in other ACLs
>>
>
> Wrong. For iSCSI, Section 2.1 of RFC-3720 defines it as TargetName +
> TargetPortalGroupTag, and this is the method that all of my upstream
> work and any proper implemention of target node endpoint and target
> portal group assignement.
>
>> 2. Initiator name - to assign it to the corresponding ACL.
>>
>> It doesn't matter if those names are IQNs for iSCSI or WWNs for FC, or
>> bus:id:lun for parallel SCSI.
>>
>> For example, consider target "TTT", which has 2 ACLs: "Default" with
>> Device1 as LUN 0 and "Group1" with "Device2" as LUN 0. "Group1"
>> specified for initiator "III1". Then when initiator "III1" connected to
>> target "TTT", it would be assigned to "Group1" and see "Device2". If
>> then initiator "III2" connected, it would be assigned to "Default" ACL
>> and see "Device1". "Default" group can be empty, if necessary. There's
>> nothing transport specific in this approach at all.
>>
>
> Your example limits all iSCSI ACLs to TargetName, instead of TargetName
> +TargetPortalGroupTag.
>
> That is why everything related to iscsi_target_mod operation is
> below /sys/kernel/config/target/iscsi/$IQN/$TPGT and
> not /sys/kernel/config/target/iscsi/$IQN.
>
> Obviously I am not going to limit my upstream iscsi_target_mod to an ACL
> structure that does not take into account a complete RFC-3720
> implementation, but I would be more than happy to see you update your
> ACL code to reflect proper TargetName+TargetPortalGroupTag that RFC-3720
> lays out for the iSCSI Target Port <-> SCSI Target Port mapping.
>
>> I strongly suggest you to look at SCST access control approach and make
>> sure you understand it before reply. It would save us a lot of time and
>> effort. Note, this approach isn't something theoretical. It's proved by
>> 4 years of successful usage.
>
> I don't really care about history, I care about code. Why don't you
> start breaking out which code you want to go upstream so that it makes
> my job easier or start integrating your own ACL control model into
> drivers/lio-core/target_core_configfs.c and post a patch and then we can
> discuss!
>
> In all honesty however, the ACL code is a small nit-pick compared to how
> we are going to merge your $FABRIC <-> $TARGET API with
> drivers/lio-core. Why don't you start there first while I consider what
> can be made generic for ACL code for the target_core_mod configfs
> upstream work.
>
>
>> Also, it would be good, if you shift your terminology to be less iSCSI
>> specific and use the corresponding terms from SAM, where possible. We
>> are discussing a config interface for a generic target engine, aren't
>> we? Otherwise sometimes it's quite hard for me to understand you and I
>> have strong suspicions that other people are getting or already got lost
>> in it.
>>
>
> Heh, why do you think I moved my upstream work to ConfigFS..? Being
> able to use two 'mkdir -p' and two 'ln -s' to create two iSCSI Initiator
> Node ACLs and four iSCSI Initiator Node ACLs is as easy as it gets!?
>
> Being able to call a *SINGLE* mkdir -p to create Network Portal on an
> iSCSI Target Portal Group, and from an unloaded iscsi_target_mod preform
> four different iSCSI target mod ops is a simple as it gets
>
> target_core_mod is a generic target engine that uses the most advanced
> and complete iscsi_target_mod, so one must put effort into understanding
> the drivers/lio-core/*configfs* to understand the simplicity of the
> code.
>
>>>> Thus, I believe, all the ACL management should be done not in $FABRIC/,
>>>> but in $TARGET/. It would remove all the corresponding configfs
>>>> headaches from the target drivers writers.
>>>>
>>>
>>>> But, in fact, I asked about completely different thing. SCSI target
>>>> mid-layer in some cases needs to export in user space amount of data,
>>>> which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What
>>>> should we do for it?
>>>>
>>> I did address point above in my work, and my commits
>>> under /sys/kernel/config/target/iscsi implement how I get around the
>>> PAGE_SIZE limitiations, which was something that I ran into (moving from
>>> IOCTL and all, which requires overly complex kernel level information
>>> code to get lots of output), to using ConfigFS, which has the same as
>>> procfs and sysfs limits that you need to use seq_file() for > PAGE_SIZE.
>>> Anyways, I did not end up using seq_file() for iscsi_target_mod current
>>> configfs code, here is what I am using to address your above example wrt
>>> getting all of session output:
>> Hmm, I looked at the code and in lio_target_initiator_nacl_info() saw
>> something like:
>>
>> rb += sprintf(page+rb, "LIO Session ID: %u "
>> "ISID: 0x%02x %02x %02x %02x %02x %02x "
>> "TSIH: %hu ", sess->sid,
>> sess->isid[0], sess->isid[1], sess->isid[2],
>> sess->isid[3], sess->isid[4], sess->isid[5],
>> sess->tsih);
>> rb += sprintf(page+rb, "SessionType: %s\n",
>> (SESS_OPS(sess)->SessionType) ?
>> "Discovery" : "Normal");
>> rb += sprintf(page+rb, "Cmds in Session Pool: %d ",
>> atomic_read(&sess->pool_count));
>> rb += sprintf(page+rb, "Session State: ");
>>
>> It doesn't look for me like it addresses the PAGE_SIZE limitation issue.
>>
>
> You are still completely missing the point here.. Because I broke out
> my projects *LEGACY* information code (just like every other upstream
> project is required to do) I do not have gigantic nested loops in my
> target_core_mod and iscsi_target_mod code that can only dump output
> using seq_file() out of procfs or through god awful IOCTL code.
>
> Every other upstream project that *HAS* broken out its legacy
> informational code into sysfs (which again, has the same limitiation) or
> another sane virtual FS control interface (like configfs) is working
> just fine. Sysfs is used by people on many many millions of Linux
> boxes, and all existing upstream projects that use sysfs have no problem
> getting lots and lots and lots of info using /bin/cat even with the
> PAGE_SIZE limitiation in place.
>
> So this means you have two choices:
>
> *) Fix your legacy code to use a sane informational output interface for
> your upstream branch.
>
> *) Produce a patch to solve the limitiation and produce an API and post
> it to linuxfs-devel.
>
> Again, for my upstream work with iscsi_target_mod, everyone will just be
> using '/bin/cat' and wildcards (*) to grok the thousands
> of /sys/kernel/config/target/iscsi/$IQNs configfs objects running on the
> production systems. Because of this reason, I am not pained by this
> limitiation (as some of your code appears to be) so please don't expect
> me to produce this patch.
Sorry, Nicholas, but it's pretty hard to discuss something with you.
Your complicated manner to express yourself (this isn't a critic, just
statement of fact, I'm also pretty much not an ideal in this area)
requires from your interlocutor a lot of effort to simply understand
you, but I don't feel that you put comparable effort to understand
what's written to you.
Let's restart our discussion and do it step by step. At first, some of
terms you use are pretty confusing for me and, I suspect, many other
people, as well as some terms I use seem confuse you. So, let's start
from finding a common terminological ground. It will remove future
misunderstandings and allow people to easier follow us. Below I'll
propose some terms. I'll tried to make them as close to the regular
Linux practice as possible, but if I'm not right somewhere everybody is
welcome to correct me.
1. Let's use term "SCSI transport" instead of "fabric", which you use.
This is well corresponding to the regular Linux practice as well as to
SAM. Particularly, SAM doesn't have the word "fabric" anywhere.
2. Target name - an opaque string passed from target driver to SCSI
target mid-layer. It contains whatever the target driver would like. For
example, for iSCSI it can be Target Name, or Target Port Name + Target
Portal Group Tag in string form. For Fibre Channel it can be WWN of the
corresponding target port. For parallel SCSI it can be target's
bus:id:lun numbers in string form. SCSI target mid-layer uses it to
provide access control.
3. Initiator name - an opaque string passed from target driver to SCSI
target mid-layer. It contains whatever the target driver would like. For
example, for iSCSI it can be Initiator Name, or Initiator User Name @
Initiator Name in string form, like
joe@iqn.1996-04.de.suse:01:1661f9ee7b5. For Fibre Channel it can be WWN
of the corresponding initiator port. For parallel SCSI it can be
initiator's bus:id:lun numbers in string form. SCSI target mid-layer
uses it to provide access control.
Next, how access control works in SCST. A target driver registers using
scst_register() a "target", which is an opaque object, used by target
mid-layer to group sessions and some other related activities. It can be
for target port for Fibre Channel or Target Portal, or Target Portal
Group for iSCSI. During registration the target driver supplies target's
name (see above its definition). Then, the target driver registers each
new session using scst_register_session() binding it to the already
registered target. During registration it provides initiator's name (see
above it's definition).
The target mid-layer has predefined by administrator a set of ACLs. Each
ACL contains a list of LUNs and a list of initiator names allowed to be
bound to this group. There are also special "default" ACLs: one per each
target (i.e. target name) and one global for targets without default ACL
defined. In scst_register_session() the target mid-layer goes over all
ACLs searching for one, containing the initiator name. If such ACL
found, the session bound to it. If no such ACL found, the target
mid-layer looks if the corresponding target has default ACL defined. If
there is such ACL, the session bound to it. Otherwise, it's bound to the
global default ACL.
Such approach has the following 2 advantages:
1. It's pretty simple to implement
2. It's transport independent. The only duty target drivers have with it
is to do initiators authentication to be sure that the initiator name
isn't a fake one. Most transports don't need such authentication. In
fact, AFAIK, currently in Linux only iSCSI transport supports it. So, in
this approach most target driver are *completely* free from caring about
access control, *everything* is done by the mid-layer.
With your approach you push a lot of access control functionality from
the target mid-layer to target drivers. Particularly:
1. Target driver need to care about user space configuration interface
and each target driver will have a duplicated code. Is it good with tens
of target drivers?
2. You need to define and then maintain the corresponding interface
between target drivers and target mid-layer for access control helpers
functions, provided by the target mid-layer to target drivers.
From other side, your approach don't have any advantages over one
already used by SCST, which I described above.
Next, the PAGE_SIZE limit issue.
What you have implemented is "access allowed only for explicitly
specified initiators and forbidden for all others". But there is also
another approach: "access forbidden only for explicitly specified
initiators and allowed for all others". How about it? In fact, it's a
lot wider used in practice, than one you've implemented.
Then, if we add the "others are allowed" mode, we need a way to somehow
show from the kernel to user space a list of such initiators. This list
can be potentially huge with thousands of entries. Also the target
mid-layer also needs a way to show all existing sessions with some
transport independent parameters, like ACL, to which each session bound,
count of outstanding commands, etc.
Thus, the need to show big lists is unavoidable. We can do it only in
the following 3 ways. Correct me, if I wrong.
1. Add in configfs ability to display large files. This looks for me as
a huge piece of work, which can easily take many months to be properly
done, so I don't think this is an option for us.
2. Add a sysfs hierarchy in which we would be able to create for each
list entry we want to show a dedicated subdirectory, in with we would
show all the necessary attributes as one or more files. Like:
/sys/scsi_target/
`-- target
`-- sessions
`-- session1
| |-- initiator_name
| |-- target_name
| |-- acl_name
| `-- commands
|
`-- session2
| |-- initiator_name
| |-- target_name
| |-- acl_name
| `-- commands
|
.
.
.
In this case we would have 2 /sys hierarchies: one in sysfs and one in
configfs. It's pretty much bad looking, isn't it?
3. Don't use configfs at all and do everything in sysfs. Actually, I
don't see any real difference between:
# mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260"
and
# echo "add_target $DEF_IQN 72.16.201.137:3260"
>/sys/scsi_target/iscsi/control
as well as between:
# ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0"
"$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0/."
and
# echo "add_lun $DEVICE_NAME" >/sys/scsi_target/acls/$DEF_IQN/control
Next, I haven't started breaking SCST code on one which should go to
upstream and which shouldn't, because it's already "broken" a lot ago.
All the /proc interface concentrated in scst_proc.c file and this file
interacts with SCST core via well defined interface. All other SCST code
in my opinion should go as is. I don't see what STGT or (sorry) LIO core
can add to it. It's pretty much well polished.
Finally, I very much dislike your "my upstream iscsi_target_mod" and "my
upstream work" kind of attitude. This is *our* work, right? Or should I
stop wasting my time in a discussion with predefined result?
Vlad
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-10-21 18:21 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-29 19:21 [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7 Nicholas A. Bellinger
2008-10-01 17:36 ` Vladislav Bolkhovitin
2008-10-02 0:24 ` Nicholas A. Bellinger
2008-10-02 17:00 ` Vladislav Bolkhovitin
2008-10-02 21:29 ` Nicholas A. Bellinger
2008-10-03 23:14 ` Nicholas A. Bellinger
2008-10-07 9:56 ` Vladislav Bolkhovitin
2008-10-07 20:50 ` Nicholas A. Bellinger
2008-10-08 7:22 ` Nicholas A. Bellinger
2008-10-10 17:49 ` Vladislav Bolkhovitin
2008-10-10 17:48 ` Vladislav Bolkhovitin
2008-10-10 20:41 ` Nicholas A. Bellinger
2008-10-21 18:11 ` Vladislav Bolkhovitin
2008-10-02 0:18 ` Nicholas A. Bellinger
2008-10-02 0:32 ` Nicholas A. Bellinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).