SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI:Data Recovery from digest errors ...



    
    Mallikarjun,
    
    Thanks for the clarification.
    
    Deva
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Mallikarjun C.
    Sent: Tuesday, August 21, 2001 7:05 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI:Data Recovery from digest errors ...
    
    
    Deva,
    
    InitialR2T=no only implies that an *initial* unsolicited
    burst is allowed by the target - _not_ that R2T is completely
    disabled.  For complete details, see rev07, Appendix D, item 24.
    
    Data sequence numbers always follow the rules clearly outlined
    in section 1.2.2.3.  R2T is a request to transfer certain data
    range, *not* PDU sequence range (as does a SNACK).
    
    I hope that addresses your questions.
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    >Mallikarjun,
    >
    >Thanks for the input.  I thought about it. I like the way of using R2T
    >to retry the data. But on further thoughts I have some
    >clarifications/concerns.
    >
    >At the outset, it looks to me to open the door for having the
    >target solicit for data (unless some restrictions are on the R2T) even
    >though  R2T is disabled as initR2T is disabled.. But R2T PDU has all the
    >relevant field
    > data offset, data length etc and fits in to retry data. Now, If out of 64K
    >received,
    >target desires to choose to retry the 16K,say between 32K to 48K, what will
    >be the data
    >sequence numbers generated for the data PDUs sent as response to R2T. Will
    >it be the
    >same sequence number for Data PDUs when they were sent as unsolicited burst
    >or a different
    >one? What will be the value of the value of expR2TSN and expDataSN in the
    >SCSI response PDU for this case. Probably a flag in the R2T header indicate
    >that
    >it is a retry for immediate and the initiator should resend the entire
    >data..
    >
    >If an initiator/target have to still be capable of supporting R2T when it
    is
    >disabled,
    >why would R2T and unsolicited data burst be mutually exclusive in the iSCSI
    >spec? Meaning,
    >if a command request is for 64K write and unsolicited burst size is 32K,
    why
    >not the target
    >receive the rest of the data (the next 32K) through R2Ts?
    >
    >Am I missing something?
    >Just my thoughts. what do you think? If Im on the wrong track, could you
    >correct me?
    >
    >
    >
    >Thanks
    >
    >Deva
    >Platys Communications
    >
    >
    >
    >-----Original Message-----
    >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    >Mallikarjun C.
    >Sent: Tuesday, August 21, 2001 3:07 PM
    >To: deva@stargateip.com
    >Cc: ips@ece.cmu.edu
    >Subject: Re: iSCSI:Data Recovery from digest errors ...
    >
    >
    >Deva,
    >
    >Let me respond to your questions.
    >
    >Currently, the draft assumes that recovery R2Ts can be generated
    >for digest errors on unsolicited data bursts in separate data PDUs.
    >This will be explicitly called out as I said in a response to Sandeep:
    >
    >http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html
    >
    >The immediate data digest failures however, are not intended to
    >be recoverable with R2Ts since an iSCSI (and SCSI) task is not
    >instantiated in that case (rev07, section 7.2).  The rationale
    >was that it is much easier for the initiator to re-ship the entire
    >PDU (command+immediate) than build a new data PDU with a Write-data
    >header (if only a part, command, of the rejected PDU were accepted
    >on  the target).   Also, accepting partial PDUs didn't seem to make
    >it easier for targets either.
    >
    >New wording dealing with immediate data digest failures had already
    >been added to section 7.2, to appear in rev08.
    >
    >Thanks.
    >--
    >Mallikarjun
    >
    >
    >Mallikarjun Chadalapaka
    >Networked Storage Architecture
    >Network Storage Solutions Organization
    >MS 5668	Hewlett-Packard, Roseville.
    >cbm@rose.hp.com
    >
    >>Julian,
    >>
    >>I dont know if this has been already discussed. If so forgive me and point
    >>me to the link please.
    >>
    >>In Section 7.4, in draft 7 (page 115)it is stated that the target may
    >>request retransmission
    >>with a R2T. It then goes on to say that non-data PDU. It does not talk
    >about
    >>unsolicited data PDUs, explicitly.
    >>I presume that data digest errors in unsolicited and immediate data PDUs
    >>cannot be retried and should be responded
    >>with delivery-subsystem failure. Is this correct? If so, why is this
    >>requirement ?
    >>
    >>In section 7.11.1, page 119, the spec. implies that digest errors in data
    >>PDUs may be recovered by issuing R2T. Once again,
    >>it fails to talk about digest errors in immediate data unsolicited data
    >>PDUs.
    >>
    >>Thanks
    >>
    >>Deva
    >>Platys communications
    
    


Home

Last updated: Tue Sep 04 01:03:56 2001
6315 messages in chronological order