Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7

[Vladislav Bolkhovitin <vst@vlnb.net>]

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
>>
> 
>