Andrew M. Hettinger wrote:
>
> 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).
>
I assume you are referring to iSCSI target (comstar is multi
protocol). I think we already have that ability on the iSCSI initiator
side so doing it for the iSCSI target should not be a problem.
Sumit
>
>
> 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
>
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
