lkml.org 
[lkml]   [2008]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [ANNOUNCE]: ConfigFS enabled Generic Target Mode and iSCSI Target Stack on v2.6.27-rc7
    From
    Date
    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
    >



    \
     
     \ /
      Last update: 2008-10-02 23:33    [W:0.037 / U:0.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site