RE: iSCSI question

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

Additionally (and with all due respect to the protocol
inventors), the recovery levels do not take into account
the problems most likely to be encountered.

As someone had previously pointed out, recovery from
failed connections is likely to be most used
(and should be disjoint from recovery within a
command due to digest errors which is probably
most useful for legacy tape). The person referred to
it as recovery level 0.5.

Even though the initiator has significant flexibility in
the model to use, the target is fairly hosed in this regard.

But time to close the spec.

Somesh



> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Mark Bakke
> Sent: Wednesday, August 07, 2002 10:03 AM
> To: Julian Satran
> Cc: Shahram Davari; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: Re: iSCSI question
> 
> 
> 
> Julian-
> 
> Your comment is accurate, but I just want to make sure that the
> readers take "last resort" properly.  From a technical, iSCSI
> point of view, it's the last resort.
> 
> However, from a practical (implementation/deployment) point of
> view, session recovery is not all that drastic.  We have been
> shipping iSCSI drivers and targets that do session recovery for
> quite a while, and it works just quite well for disks (the OS
> SCSI layer handles any retries), and for tape applications that
> support re-positioning, which are becoming more common.  We
> have spent a significant amount of time testing this both in
> our lab and in the field.
> 
> <SOAPBOX>
> Once tape device and driver vendors support SSC-2, there should be
> no need to do more than session recovery, except perhaps for
> some performance advantages environments where a lot of connection
> recovery needs to take place.  But for most iSCSI environments,
> doing more than session recovery is not necessary.
> </SOAPBOX>
> 
> --
> Mark
> 
> Julian Satran wrote:
> > 
> > Session recovery means just creating a NEW session and 
> forgetting about all old commands.
> > It is the last resort recovery where everything else fails and 
> as such it is the most basic
> > function - that anybody has to have.
> > 
> > Julo
> > 
> >   Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >                                                          To:    
>     Julian Satran/Haifa/IBM@IBMIL
> >   08/07/2002 06:43 PM
> >                                                          cc:    
>     ips@ece.cmu.edu,
> >                                                  owner-ips@ece.cmu.edu
> >                                                          
> Subject:        RE: iSCSI question
> > 
> > 
> > 
> > Julian,
> > 
> > To start a new session you need to start new connections and 
> you need to support
> > the PDU recovery. So how is that a subset of PDU and connection 
> recovery?
> > 
> > 
> > -Shahram
> > 
> > (I will explain the detailed clarity issues in another email)
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 07, 2002 11:34 AM
> > To: Shahram Davari
> > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> > Subject: RE: iSCSI question
> > 
> > Session recovery is in fact leaving all recovery to SCSI - it 
> drops everything and creates a new
> > session.
> > As for you comment on the clarity of chapter 5 at this stage it 
> makes sense to be either specific
> > or keep this type of comment out of this context.
> > 
> > Julo
> > 
> >    Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >                                                            To:  
>       Julian
> >    08/07/2002 06:09 PM                              
> Satran/Haifa/IBM@IBMIL
> >                                                            cc:  
>       ips@ece.cmu.edu,
> >                                                     
> owner-ips@ece.cmu.edu
> >                                                            
> Subject:        RE: iSCSI question
> > 
> > 
> > 
> > Julian,
> > 
> > Thanks. I have read that section but it is not very clear.
> > 
> > I also agree that Connection recovery requires everything in 
> command recovery.
> > But what about session recovery? isn't it a superset of both 
> connection and command recovery?
> > 
> > Yours,
> > -Shahram
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 07, 2002 11:03 AM
> > To: Shahram Davari
> > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> > Subject: Re: iSCSI question
> > 
> > Sharam,
> > 
> > You may want to go over the recovery chapter.
> > It has detailed answers to all your questions.
> > The superset/subset is based on functions you need for the next level.
> > 
> > Session recovery drops real recovery to SCSI.
> > Command recovery recovers from individual command errors without
> > changing connection and the highest enable you to switch to a 
> new connection and
> > continue commands there.
> > 
> > 2 requires everything in 1.
> > 
> > Julo
> >    Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >    Sent by: owner-ips@ece.cmu.edu                               
>        To:        ips@ece.cmu.edu
> > 
> >    08/07/2002 05:17 PM                                          
>        cc:
> >                                                                 
>        Subject:        iSCSI
> >                                                                 
>  question
> > 
> > 
> > 
> > Hi,
> > 
> > I have a question regarding the hierarchy of error recovery.
> > Section 6.13 mentions the hierarchy as:
> > 
> > 2: Connection recovery
> > 1: Digest failure recovery
> > 0: Session recovery
> > 
> > And it states that the higher levels are a superset of the
> > lower levels and that the level of complexity increases from 0->1->2.
> > 
> > Couple of questions:
> > 
> > 1) How is digest failure recovery done? by retransmission of PDUs?
> > 2) Why is the connection recovery a superset of session recovery
> > and more complex?
> > 3) It seems to me the order should be:
> > 
> > 2: Session recovery
> > 1: Connection recovery
> > 0: Digest failure recovery
> > 
> > I appreciate any insight.
> > 
> > Thanks,
> > -Shahram
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054