SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI : Initiators expected to fake CHECK CONDITIONS.


    • To: IPS Reflector <ips@ece.cmu.edu>
    • Subject: iSCSI : Initiators expected to fake CHECK CONDITIONS.
    • From: Santosh Rao <santoshr@cup.hp.com>
    • Date: Tue, 09 Jan 2001 19:05:43 -0800
    • Content-Type: multipart/mixed;boundary="------------981462BFADCD0BBD099F400A"
    • Organization: Hewlett Packard, Cupertino.
    • Sender: owner-ips@ece.cmu.edu

    Julian,
    
    My comments embedded below.
    
    Thanks,
    Santosh
    
    > Section 4.4. Format Errors
    > ====================
    > Quoting from the draft :
    
    > "When a session is active whenever an initiator receives an iSCSI PDU
    >  with a format error, for which it has an outstanding task, it MUST
    >  abort the target task and report the error as a SCSI check condition
    >  status with a sense key of 4h (hardware error)."
    
    > What is the reasoning behind this ? It seems to complicate Format
    Error
    > Handling with no clear benefit. Is it the expectation that iSCSI
    > initiators
    > will fake a format error as a CHECK CONDITION back to the SCSI
    >Layer ? If so, why ? And why the choice of "Hardware Error" ?
    
    [js} the error was generated by a faulty controller and I did not find
    any
    other SCSI sense fit for it[/js]
    
    A clean layering should be maintained between iSCSI layer errors and
    SCSI layer errors. A format error on a iSCSI PDU header does not
    constitute a SCSI error. The specific error returned back to the
    SCSI upper layer driver in this case is really O.S. specific since each
    O.S. has its own error codes to deal with interconnect transport errors.
    
    Expecting initiators to fabricate sense data on behalf of a target and
    faking a CHECK CONDITION back to the upper layers is :
    a) violating layering b/n iSCSI and SCSI layers.
    b) adds un-necessary complexity to the initiator which now needs to
    build sense data internally on behalf of a target.
    c) will cause different error recovery paths to be taken in the upper
    layer SCSI driver which is expecting to see some std O.S. defined error
    codes to be returned on interconnect transport errors.
    
    
    > Last, but not the least, the above statement is referring to all iSCSI
    
    > PDUs and advocates that iSCSI initiators must fake a CHECK CONDITION
    > back to the SCSI layer on any format error of any iSCSI PDU.
    
    [js] only if a task is running [/js]
    
    I'm somewhat confused here. Let us say a format error occurs on a
    Logout. What is the error recovery to be done in this case if there are
    other outstanding tasks ? Is this section advocating erroring ALL the
    outstanding tasks [that did not encounter format error] ?
    
    
    > This is not applicable for non-scsi iSCSI PDUs which have no SCSI
    > context. I believe the REJECT PDU should only be used for non-scsi
    > PDUs since Rejects to SCSI PDUs will need a different type of reason
    > code/explanation information best fitted into the existing SCSI
    Response
    
    
    
    begin:vcard 
    n:Rao;Santosh 
    tel;work:408-447-3751
    x-mozilla-html:FALSE
    org:Hewlett Packard, Cupertino.;SISL
    adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
    version:2.1
    email;internet:santoshr@cup.hp.com
    title:Software Design Engineer
    x-mozilla-cpt:;21088
    fn:Santosh Rao
    end:vcard
    


Home

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