SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Naming and Discovery Draft...



    
    
    Strange English.  In computerese committed is associated usually with:
    
    - written successfully to stable media (like in committed to disk)
    - transaction unit completed (transaction commit)
    
    Even in informal English it is used as a negation only in statements like
    "sorry, I had other (previous) commitments".  When left alone it has
    "positive connotation" (like I am committed to do it).
    
    You fellows don't make learning American an easy exercise for us poor
    non-native speakers  -:)
    
    On a more serious tone:
    
    with controlers and devices busy is usually meant to convey 2 things:
    
    - I am busy for a short interval
    - I will tell you when I get free
    
    If you don't intend to tell when you become free don't use busy.
    
    You can use occupied (like in "lavatories occupied" - I am in an airplane
    now -:))
    It conveys exactly what you want.
    
    Don't take me too serious - I am not good at naming but don't over-commit
    committed.
    
    Julo
    
    
    Mark Bakke <mbakke@cisco.com> on 08/03/2001 16:01:27
    
    Please respond to Mark Bakke <mbakke@cisco.com>
    
    To:   "Elliott, Robert" <Robert.Elliott@compaq.com>
    cc:   ips@ece.cmu.edu, "'Renato E. Maranon'"
          <rmaranon@marantinetworks.com>, klein@sanrad.com, "'Tanjore K.
          Suresh'" <Tanjore.Suresh@sun.com>
    Subject:  Re: iSCSI: Naming and Discovery Draft...
    
    
    
    
    Sounds like we are left with "Target Committed", which
    Renato's new description seems to fit.
    
    Any other ideas, or does that seem to work?
    
    --
    Mark
    
    "Elliott, Robert" wrote:
    >
    > "Busy" and "Reservation Conflict" are SCSI Status code names defined in
    > SAM-2; I'd avoid using them for this different purpose.
    > ---
    > Robert.Elliott@compaq.com
    > Compaq Server Storage
    >
    > > -----Original Message-----
    > > From: Renato E. Maranon [mailto:rmaranon@marantinetworks.com]
    > > Sent: Wednesday, March 07, 2001 11:12 AM
    > > To: klein@sanrad.com; 'Tanjore K. Suresh'
    > > Cc: ips@ece.cmu.edu
    > > Subject: RE: iSCSI: Naming and Discovery Draft...
    > >
    > >
    > > My two cents.  I like to suggest "Target Reserved", "Target
    > > Reservation
    > > Conflict" or "Target Committed".  For this condition to
    > > occur, the target
    > > may not be necessarily busy, but just out of resources, or
    > > can only handle
    > > one.  "Target Busy" seems to imply busy.  Building on Mark's
    > > desciption
    > > below, something like:
    > >
    > >    The target has committed resources to one or more
    > > initiators and cannot
    > > handle
    > >    another one. The initiator MAY try again later. This can
    > > be the case
    > >    for simple devices that can handle only one initiator at a time, or
    > >    for a target that has does not have the resources to
    > > support one more
    > >    initiator.  In contrast to the  previous examples, this
    > > rejection is
    > >    temporary.
    > >
    > >
    > >
    > > Renato Maranon
    > > Maranti Networks, Inc
    > > 920 Hillview Court
    > > Milpitas, Ca 95035
    > > Phone:  408-719-9600 x309
    > > Fax:    408-719-9631
    > > email:  rmaranon@marantinetworks.com
    > > home:   www.marantinetworks.com
    > >
    > >
    > > -----Original Message-----
    > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > > Yaron Klein
    > > Sent: Wednesday, March 07, 2001 1:38 AM
    > > To: 'Tanjore K. Suresh'
    > > Cc: ips@ece.cmu.edu
    > > Subject: RE: iSCSI: Naming and Discovery Draft...
    > >
    > >
    > > Tanjore,
    > >
    > > Some more comments:
    > >
    > > The error statuses codes on Appendix B are not synchronized
    > > with the main
    > > draft. We will fix it.
    > >
    > > The term "target conflict" was borrowed from HTTP. Mark clarified this
    > > scenario well. I would like to add that this status enables better
    > > resolution and knowledge to the target. That is, in those
    > > cases the target
    > > can just not open the connection or just reject it like server error.
    > > However, this will not give indication of the situation as
    > > described by
    > > Mark.
    > >
    > > Regards,
    > >
    > > Yaron
    > >
    > > -----Original Message-----
    > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
    > > Behalf Of Mark
    > > Bakke
    > > Sent: Tuesday, March 06, 2001 6:51 PM
    > > To: Tanjore K. Suresh
    > > Cc: kaladhar@us.ibm.com; ips@ece.cmu.edu
    > > Subject: Re: iSCSI: Naming and Discovery Draft...
    > >
    > >
    > > Tanjore-
    > >
    > > Thanks for the feedback.  I can comment on #3:
    > >
    > > "Tanjore K. Suresh" wrote:
    > > >         3. Appendix B, B.4.5,
    > > >           Target Conflict 45 doesnot seem to be appropriate.
    > > >
    > > >                 I have not reviewed all the documents yet to give a
    > > >                 recommendation and hence cannot give, but feel
    > > >                 " Target Conflict" doesnot
    > > >                 convey the meaning of the Scenario indicating
    > > >                 case of " simple devices that can handle
    > > one device or
    > > >                 the target had reached the limit of its Initiators'
    > > capacity."
    > >
    > > Perhaps we chose the wrong term for this one.  How about if call it
    > > "Target Busy", and slightly re-word it?
    > >
    > >    The target is busy with another initiator and cannot handle
    > >    another one. The initiator MAY try again later. This can
    > > be the case
    > >    for simple devices that can handle only one initiator at a time, or
    > >    for a target that has does not have the resources to
    > > support one more
    > >    initiator.  In contrast to the  previous examples, this
    > > rejection is
    > >    temporary.
    > >
    > > --
    > > Mark A. Bakke
    > > Cisco Systems
    > > mbakke@cisco.com
    > > 763.398.1054
    > >
    
    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:24 2001
6315 messages in chronological order