* [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-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: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-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-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-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
* 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-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
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).