Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754345AbYJGJ5W (ORCPT ); Tue, 7 Oct 2008 05:57:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753946AbYJGJ5B (ORCPT ); Tue, 7 Oct 2008 05:57:01 -0400 Received: from mail-relay-03.mailcluster.net ([77.221.130.215]:49179 "EHLO mail-relay-01.mailcluster.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753451AbYJGJ45 (ORCPT ); Tue, 7 Oct 2008 05:56:57 -0400 Message-ID: <48EB325E.6050907@vlnb.net> Date: Tue, 07 Oct 2008 13:56:46 +0400 From: Vladislav Bolkhovitin User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "Nicholas A. Bellinger" CC: linux-iscsi-target-dev@googlegroups.com, FUJITA Tomonori , Mike Christie , linux-scsi , iet-dev , Greg KH , Jerome Martin , LKML , James Bottomley , SCST-Devel , Joel Becker , "H. Peter Anvin" Subject: Re: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7 References: <1222716101.4296.41.camel@haakon2.linux-iscsi.org> <48E3B529.4060406@vlnb.net> <1222907050.15764.56.camel@haakon2.linux-iscsi.org> <48E4FE3F.2080707@vlnb.net> <1222982972.15764.118.camel@haakon2.linux-iscsi.org> In-Reply-To: <1222982972.15764.118.camel@haakon2.linux-iscsi.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8819 Lines: 214 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 > > > > # 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" > > > > # 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 >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/