RE: iSCSI: "conservative reuse" requirement

[Black_David@emc.com]

Not exactly.  "Conservative Reuse" would allow an initiator
to present multiple initiator ports, as long as it presented
each of them to all target ports (assuming that the connectivity
exists).  Why would an Initiator want to present different
ports to different target portal groups?  I don't think there's
another example in which SCSI behaves this way in practice.

--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, December 24, 2001 12:47 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: "conservative reuse" requirement
> 
> 
> > I think this is headed towards "conservative reuse" being a MUST if
> > we're serious about support for shared persistent reservations.
> 
> Mandating "conservative reuse" appears to force initiators to 
> always act
> as a single initiator port (wrt one target; assuming only one 
> session as an
> example) per initiator device - which rules out the case of 
> an initiator 
> intentionally wanting to present a different port to each 
> target portal group.
> 
> IMHO, if iSCSI provides an architected mechanism to support shared 
> persistent reservations ("conservative reuse"),  that should 
> be completely 
> adequate to meet the expectations to be a legal SCSI protocol.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668 
> Roseville CA 95747
> 
> ----- Original Message ----- 
> From: <Black_David@emc.com>
> To: <santoshr@cup.hp.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Friday, December 21, 2001 4:50 PM
> Subject: iSCSI: "conservative reuse" requirement
> 
> 
> > Santosh Rao writes:
> >  
> > > I am opposed to the suggestion that "conservative re-use" 
> of ISIDs be
> > > made a MUST. This is really only required when initiators 
> need to be
> > > using the new T10 Reservation scheme that can be shared 
> > > across initiator ports.
> > 
> > Those reservations are a Target feature.  With this 
> approach, the ability
> > to use the target feature depends on details of the initiator
> > implementation.
> > More below ... 
> >  
> > > For those initiators that don't care about this type of 
> reservation,
> > > conservative re-use is of no use and initiators may like to assign
> > > ISID's in a per-initiator node fashion, thereby, being 
> able to use these
> > > ISIDs as a lookup index for the sessions on that initiator node.
> > > 
> > > Hence, I suggest that "conservative re-use" be worded as 
> > > "encouraged to use" or something to that effect, but not MUST USE.
> > > 
> > > Comments ?
> > 
> > The "initiator" is more than one entity.  The iSCSI HBA/NIC 
> and driver
> > doesn't know whether shared persistent reservations are 
> being used and
> > shouldn't have to care - they're just more SCSI commands to 
> transport.
> > Some other entity (e.g., clustering software) will be generating the
> > shared persistent reservations.  This raise the possible scenario
> > involving a target that supports the new shared persistent 
> reservations
> > and an entity that wants to use them.  The entity detects 
> (via SCSI means,
> > e.g., something in a mode page) that the Target supports 
> shared persistent
> > reservations, tries to use them, only to discover that they 
> don't work
> > because the iSCSI HBA/NIC doesn't implement "conservative reuse".
> > 
> > I'm worried about this causing both interoperability issues 
> and possible
> > T10 issues -- from a T10 viewpoint, if shared persistent 
> reservations
> > don't work, the initiating entity should have some SCSI-level means
> > of determining this ... if that means exists only on the Target, the
> > above scenario is iSCSI's problem (Target can't query Initiator to
> > determine whether it does "conservative reuse"), and having 
> a separate
> > initiator side means that the entity has to check only for 
> iSCSI (and
> > not for any other SCSI transport) does not seem like the right
> > approach.
> > 
> > I think this is headed towards "conservative reuse" being a MUST if
> > we're serious about support for shared persistent reservations.
> > 
> > Comments?
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> > black_david@emc.com         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > 
>