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@xxxxxxxxxxxxxxxx > To unsubscribe from this group, send email to linux-iscsi-target-dev+unsubscribe@xxxxxxxxxxxxxxxx > For more options, visit this group at http://groups.google.com/group/linux-iscsi-target-dev?hl=en > -~----------~----~----~----~------~----~------~--~--- > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
