SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    ---------------------------------------------------
    
    


Home

Last updated: Mon Dec 24 01:17:48 2001
8199 messages in chronological order