SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Implicit Termination of Tasks



    Eddy,
    
    iSCSI's design goal was to ensure command ordering 
    even in the face of errors - ultimately, we wanted the SCSI 
    execution ordering to be correct while running on iSCSI.
    This should be able to be guaranteed by the iSCSI targets, 
    while initiators may/may not employ command ordering.
    
    For this to happen, iSCSI must both maintain its delivery
    ordering, and require SCSI CHECK CONDITIONs to
    be locally triggered on the target on iSCSI exception 
    conditions such as connection terminations.  The CHECK
    CONDITION would then cause the ACA/persistent-UA to
    be invoked if so desired by the initiator. 
    
    This is not "a method of implementing", it's required behavior
    to meet iSCSI's architectural guarantee of command ordering. 
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions
    Hewlett-Packard MS 5668 
    Roseville CA 95747
    cbm@rose.hp.com
    
    
    ----- Original Message ----- 
    From: "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
    To: "'Mallikarjun C.'" <cbm@rose.hp.com>; <ips@ece.cmu.edu>
    Sent: Monday, January 06, 2003 12:46 PM
    Subject: RE: iSCSI: Implicit Termination of Tasks
    
    
    > Yes, I noticed my typo of "two" vs. "three" but too late.
    > 
    > Below you say that the ordering is iSCSI ordering but section 6.5 is saying
    > SCSI ordering (queued commands is SCSI). So, that leaves me a little
    > confused as to what this paragraph is trying to say, especially when the
    > "status is never communicated back ... to the initiator".
    > 
    > I'm probably mis-understanding something. It appears as though this is just
    > a method of implementing within the target.
    > 
    > Eddy
    > 
    > -----Original Message-----
    > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
    > Sent: Monday, January 06, 2003 3:12 PM
    > To: Eddy_Quicksall@ivivity.com; ips@ece.cmu.edu
    > Subject: Re: iSCSI: Implicit Termination of Tasks
    > 
    > 
    > Comments below.
    > --
    > Mallikarjun
    > 
    > Mallikarjun Chadalapaka
    > Networked Storage Architecture
    > Network Storage Solutions
    > Hewlett-Packard MS 5668
    > Roseville CA 95747
    > cbm@rose.hp.com
    > 
    > ----- Original Message -----
    > From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
    > To: <ips@ece.cmu.edu>
    > Sent: Monday, January 06, 2003 5:16 AM
    > Subject: iSCSI: Implicit Termination of Tasks
    > 
    > 
    > > There are two sections titled Implicit Termination of Tasks but they
    > are
    > > slightly different. Which is correct?
    > 
    > Both are correct and consistent.
    > 
    > >
    > > Section 6.5 lists 4 items but section 10.14.5 only lists two.
    > 
    > I'm seeing three in 10.14.5.....
    > 
    > Even though 6.5 lists all the four cases, it makes it clear that the
    > check condition is to be employed only for three cases - and
    > only those three are listed by 10.14.5.  Perhaps the text could have
    > been a little bit more explicit about this distinction.
    > 
    > >
    > > If 6.5 is correct, why is item D not included in the unit attention?
    > SAM-3
    > > says:
    > 
    > It's not so much a SAM issue.  The issue we considered was how to ensure
    > iSCSI-standard ordered delivery of commands in the face of errors.  The
    > ordered delivery of commands does not make sense for case (d) - that of
    > creating a new session - ordering is not guaranteed anyway across
    > sessions.
    > 
    > 
    
    


Home

Last updated: Tue Jan 07 16:18:58 2003
12119 messages in chronological order