One major thing that I'm interested in is the ability to name my own
targets. That unintelligible string of hex is prone to human error, so I
would just assume use my own domain-name-space (as opposed to SUN's) and
ensure there are no duplicates myself (as is permitted
under the RFC).
Andrew Hettinger
http://Prominic.NET || [EMAIL PROTECTED]
Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l)
Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l)
Mobile direct: 1.217.621.2540
CompTIA A+, CompTIA Network+, MCP
[EMAIL PROTECTED] wrote on 10/01/2007 05:32:31 PM:
> The COMSTAR project team is beginning discussions around how COMSTAR
> will impact the user experience for the current iSCSI target. While
> we don't have all of the designs in place for the iSCSI target under
> COMSTAR, we have a feel for some items that will differ slightly
> from the existing iSCSI target implementation.
>
> One of the goals of COMSTAR is to provide as much configuration
> flexibility as possible while attempting to balance that with
> simplicity in its CLI and library interfaces. This goal of
> flexibility and simplicity also holds true for the framework logical
> unit and target provider interfaces within COMSTAR but since the
> focus here is on current iSCSI target consumers, we can leave that
> discussion for another time, one that probably targets framework
> provider interface clients rather than clients of the CLI and library.
>
> For the purposes of this and future discussions, the existing iSCSI
> target will be referred to as the current iSCSI target. References
> to the future implementation under COMSTAR will be referred to as
> COMSTAR or the COMSTAR iSCSI target.
>
> With that out of the way, here are some of the high level items that
> we know differ:
>
> 1) Targets and Logical units
>
> These items are combined here simply because they were combined
> within the iSCSI target. Tying them tightly together in the CLI, or
> anywhere for that matter, when you have more than one transport
> (i.e. iSCSI + fibre channel), can be somewhat limiting. Management
> of the logical units themselves should be completely independent of
> the target. Association of the logical unit with the target is only
> done for purposes of exporting that logical unit via one or more
> target ports. Those target ports can be of any of the supported
> transport protocol types that can transport SCSI (iSCSI, fibre
> channel, SAS, etc). The stmf framework within COMSTAR does not limit
> the type of protocol that can be implemented as a target provider.
> To that end, this existing coupling of the target and logical unit
> will no longer exist with COMSTAR. COMSTAR will treat each of these
> logical units as separate entities. The association between the
> logical unit and the target will be represented using objects te
> rmed "view entries". A logical unit that is exported via one or
> more target ports will have one or more associated view entries,
> with each describing how that logical unit is exported.
>
> 2) Target Access Control Lists
>
> The current iSCSI target uses ACLs on the target to control which
> initiators have access to the target and subsequently to the logical
> units behind that target. While the target ACL provides an
> authorization scheme at the transport level (iSCSI), it does not
> provide any authorization granularity at the logical unit level. In
> this fashion, it is an all-or-nothing approach to logical unit
> access control. As for the benefits of target level access control,
> this is one of the items that we will need to discuss further and it
> would be interesting to understand in what environments this feature
> might be useful. Logical unit access control is well understood in
> the storage industry as logical unit masking and we will use this
> terminology moving forward to describe it. Since COMSTAR's approach
> is to treat the logical units as separate entities, this logical
> unit masking strategy will change from the current iSCSI target. As
> indicated in the first item above, "Targets and Logical unit
> s", view entries will be used to describe how the logical unit is
> exported. These same view entries will also be used to describe the
> masking that is applied to the logical unit thereby describing which
> initiators have access to the logical unit.
>
> 3) Target Logical Unit Numbers
>
> The current iSCSI target provides the ability to create a logical
> unit with a specified logical unit number. This logical unit number
> cannot be modified without destroying the logical unit. While for
> most scenarios, this approach is likely sufficient, there are
> scenarios that require greater flexibility in logical unit number
> assignment for a given logical unit. This becomes particularly
> important when exporting the logical unit via multiple target ports
> and to multiple initiators. COMSTAR will move this logical unit
> number assignment, generally referred to as logical unit mapping, to
> the view entry on the logical unit. In this way, there can be
> multiple logical unit mapping definitions associated with a single
> logical unit.
>
>
> This concept of using a view entry to describe the logical unit
> export, masking and mapping attributes is described in a document on
> the OpenSolaris COMSTAR project page.
>
> http://www.opensolaris.org/os/project/comstar/files/ve_description.pdf
>
> Other than the above 3 items, the current iSCSI target largely
> remains the same since the rest of the features in the current iSCSI
> target are iSCSI specific rather than SCSI specific, so the lines of
> separation with the COMSTAR stmf framework functionality are fairly
clean.
>
> We certainly welcome discussion in this area. And if you have any
> further interest in COMSTAR, the complete project materials are
> available at the OpenSolaris project website mentioned above.
>
>
> Thanks,
> John
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
