SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: FW: iSCSI: "conservative reuse" requirement



    
    It is true that this does not need to be MUST, but it seems silly not to
    make it MUST or SHOULD.  To think that a vendor would want to have a price
    feature that has the HBA or the Device Driver using the same ISID with
    Conservative reuse, seems very unlikely.
    
    Likewise, I can not think of a customer advantage not to have Conservative
    reuse.  When a customer installs the HBA and Device Driver and then finds
    that he must change the SW or HW if he wishes to Share LUs among a number
    of Systems, that customer will be very disappointed, and will be upset if
    the vendor then tries to sell him this upgrade especially when the vendors
    do not charge extra.
    
    Since Conservative Reuse (just reusing the same ISID over and over)
    requires no more and probably less code, and has potential customer impacts
    if not done, we should strongly come down on the side of the customer.  I
    think the Spec should work to prevent this silliness, and specify either
    MUST or SHOULD.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Jim Hafner
    12/28/2001 09:14 AM
    
    To:    John Hufferd/San Jose/IBM@IBMUS, "Eddy Quicksall"
           <Eddy_Quicksall@iVivity.com>, "Mallikarjun C." <cbm@rose.hp.com>,
           Black_David@emc.com
    cc:    ips@ece.cmu.edu
    From:  Jim Hafner/Almaden/IBM@IBMUS
    Subject:    Re: FW: iSCSI: "conservative reuse" requirement  (Document
           link: John Hufferd)
    
    Folks,
    
    Sorry for taking so long to jump into this discussion.
    
    There are a number of issues raised in this thread:
    1) should "conservative reuse" of ISIDs be made a MUST
    2) does "conservative reuse" imply that all hosts look "single SCSI ported"
    
    Here's my two cents (using "CR" as a shorthand for "conservative reuse")
    
    I don't believe that CR needs to be a MUST.  The only time this has any
    real value is in configurations that use SCSI persistent reservations (and
    where new SCSI target reservation features are enabled -- NB.  these
    features are yet to be approved but are working their way through the
    process). I don't think these are going to be (even in the future) the
    majority of installations.  There are many ways then that CR could be
    something that is not generally available in most drivers but is added by
    configuration and perhaps even "value add" (:-{)).
    
    In short, I don't see a strong case for this to be a MUST.  So, to David
    Black, my answer is that having a mechanism to enable this feature or have
    it as a "purchase requirement" is an acceptable mechanism to make sure the
    feature is there when needed, but it is need not be a requirement of the
    protocol.  To Mallikarjun, I think I'm agreeing with you that so long as
    there is a mechanism defined, iSCSI has done it's job.
    
    As for the second issue (raised by Mallikarjun), let's look at the
    definition of CR.  What is means is that when an iSCSI initiator (node)
    creates ISIDs for use in session identifiers, it attempts to reuse them as
    much as possible with different SCSI target ports (iSCSI target portal
    groups).  This is the only way that a SCSI target or LU can see the same
    SCSI initiator port through two or more of its SCSI target ports -- that
    is, that the target can determine multiple paths *from* the same SCSI
    initiator port.   But, the model for generating ISIDs is not really at the
    node level but at the initiator portal group level.
    So, IMO, the conclusion that all hosts must then look "single SCSI ported"
    is too dramatic.  As I mentioned,  ISIDs are conceptually generated within
    initiator portal groups (that's why we defined the mechanism for generating
    ISIDs).  The conclusion I draw is that (assuming no more than one session
    to any given target portal group), an iSCSI initiator implementing CR will
    have as many SCSI initiator ports as iSCSI initiator portal groups
    (independent HBAs?).  Each initiator portal group would generate one ISID
    (that is different from that generated by/for the other initiator portal
    groups) and use CR for repeatability.  [This is consistent with a model
    that mapped SCSI initiator ports to initiator portal groups, which we had
    to abandon because the "assuming no more than one session..." was no
    acceptable as a requirement!!!]  This independence of ISIDs for each
    initiator portal group allows each initiator portal group to open sessions
    with *every* target portal group it knows about without having to worry
    about interfering with other sessions. [This has shades of the
    "partitioning" rule for ISIDs that has been discussed ad nauseum!!!]
    
    (I have a feeling that this note is not well composed -- it is the
    holidays, you know).  I hope I've addressed everyone's concerns and we can
    lay this one to rest.
    
    Jim Hafner
    
    
    John Hufferd
    12/25/2001 08:49 AM
    
    To:    "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
    cc:    Jim Hafner/Almaden/IBM@IBMUS
    From:  John Hufferd/San Jose/IBM@IBMUS
    Subject:    Re: FW: iSCSI: "conservative reuse" requirement  (Document
           link: Jim Hafner)
    
    You are correct.  The section was created by Jim Hafner, and via this note
    I will ask him if he could answer Mallikarjun Directly since I did not
    understand his issue.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> on 12/24/2001 06:06:44 PM
    
    To:    John Hufferd/San Jose/IBM@IBMUS
    cc:
    Subject:    FW: iSCSI: "conservative reuse" requirement
    
    
    
    John,
    
    Were you the author of "conservative reuse"? I am wondering about some
    issues. Maybe you could educate me somewhat ...
    
    I started this subject in a different thread by saying that it may be
    good to make "conservative reuse" a MUST.
    
    I got one objection from Santosh below. Then David Black picked it up
    by basically agreeing with me. Then Mallikarjun objected to that.
    
    It seems like the objective would be to give targets a way to figure
    out that two or more sessions are coming from the same Initiator Port.
    That is needed support persistent reservations.
    
    If an initiator does not use "conservative reuse", I don't think
    targets will be able to make that determination.
    
    Comments?
    
    Eddy
    
    -----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
    > ---------------------------------------------------
    >
    >
    
    
    
    
    
    
    
    
    


Home

Last updated: Sat Dec 29 19:17:45 2001
8218 messages in chronological order