SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    (Start of) iSCSI ERT: handling for iSCSI response codes



    Let me post the complete context for that email exchange,
    since I was the one proposing this change in ERT.  Please
    take time to read these short messages, I would appreciate 
    comments.
    
    One line quote from my message behind this proposal:
    
            "To summarize, IMHO, iSCSI is presumptively signaling the task 
            conclusion with its response codes."
    
    Responding to Julian:
    
    >This type of handling will let us build independent of SCSI ....
    
    Julian, the fact is that we can not completely be "independent of SCSI"
    except we start building in redundant mechanisms like ACA at iSCSI level.
    I thought we were dropping the EnableACA "feature" precisely because
    we did not want to build in this redundancy!
    
    Regards.
    --
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    --------------------------------------------------------------------------
    
    Date: Thu, 07 Jun 2001 19:37:10 PDT
    To: cbm@rose.hp.com
    Subject: iSCSI ERT: handling for iSCSI response codes
    Cc: julian_satran@il.ibm.com, someshg@yahoo.com, venkat@rhapsodynetworks.com,
    	steph@cs.uchicago.edu, ldalleore@snapserver.com, Black_David@emc.com,
    	hufferd@us.ibm.com, kalman_meth@il.ibm.com
    In-Reply-To: <200106060116.SAA00914@core.rose.hp.com>; from "Mallikarjun C." at Jun 5, 101 6:16 pm
    Status: RO
    
    Team,
    
    After exchanging some messages with Ralph Weber and Ed Gardner, 
    I am coming to the conclusion that all the error cases which 
    result in "iSCSI response codes" in the SCSI Response PDU should
    in fact result in SCSI CHECK CONDITION - to result in ACA if
    NACA=1 was set for the failing command, ie. to kick in the 
    regular SCSI processing.
    
    Following are defined in draft rev06 -
    
          0x01 - Target Failure
          0x02 - Delivery Subsystem Failure
          0x03 - Unsolicited data rejected
          0x04 - SNACK rejected
    
    Note that commands failing with any of these response codes
    would cause out-of-order execution for the follow-on commands -
    even with NACA=1, simply because iSCSI can not mandate ACA, a
    SCSI-ism, to enforce ordering (we dropped EnableACA kludge because 
    of this reason).  The solution I see is to instead have iSCSI 
    mandate a standard SCSI CHECK CONDITION on these errors with
    the current response codes acting as detailed descriptions.
    
    It turns out there are already reasonable ASC/ASCQ values 
    defined for these cases (for all SCSI device types) in SPC-2.  
    Here they are -
    
                           ASC    ASCQ          Means 
    
    Target Failure     ->  0x44   0x00       Internal Target Failure
    Delivery Subsystem ->  0x47   0x03       Information Unit CRC error
    Failure                                  detected
    SNACK rejected     ->   -do -            -do- (since the root cause
                                                  is the same)
    Unsolicited data   ->  0x49   0x00       Invalid Message Error
    rejected
    
    To summarize, I propose that iSCSI mandate CHECK CONDITION with
    the ASC/ASCQ values as shown above - instead of limiting to iSCSI
    response codes.  This cleanly takes care of the ACA issue.  There
    are precedents in SCSI Protocol standards like FCP-2 for mandating 
    such behavior.
    
    
    Comments?
    --
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    -------------------------------------------------------------------------
    
    Date: Thu, 14 Jun 2001 10:58:04 PDT
    To: steph@cs.uchicago.edu
    Subject: Re: iSCSI ERT: handling for iSCSI response codes 
    Cc: cbm@rose.hp.com, julian_satran@il.ibm.com, someshg@yahoo.com,
    	venkat@rhapsodynetworks.com, ldalleore@snapserver.com,
    	Black_David@emc.com, hufferd@us.ibm.com, kalman_meth@il.ibm.com
    In-Reply-To: <200106140242.f5E2g9603398@chmls20.mediaone.net>; from "Stephen Bailey" at Jun 13, 101 7:43 pm
    Status: RO
    
    Steph,
    
    Thanks for the message.
    
    >I'm not clear on what you're proposing for SNACK rejected, but, since
    >it's not CHECK CONDITION, I'm sure whatever you have in mind is fine,
    >but we need to document it better :^)
    
    Sorry, I was using proprietary (and confidential) shorthand, :-)
    
    Actually, I was proposing a CHECK CONDITION (0x47, 0x03) even for 
    "SNACK rejected" since the "root cause is the same" - ie. a prior data 
    integrity error! Keep in mind that employing SNACK means the task 
    is already considered in progress by both parties - the target iSCSI 
    is fabricating a SCSI Response PDU without its SCSI involvement, it's 
    technically incorrect since the task is already instantiated at its 
    SCSI layer.  That's what the source of the problem here is.
    
    To summarize, IMHO, iSCSI is presumptively signaling the task conclusion 
    with its response codes.  The correct options are 
    
    	a) iSCSI should not deliver a SCSI Response at all, forcing a timeout 
               and thus the standard SCSI recovery.
        OR
            b) iSCSI should mandate a CHECK CONDITION - which technically
               involves task cleanup at target SCSI layer, and leads to the 
               right ordering semantics.
    
    My suggestion was ofcourse (b), for faster error recovery.
    
    I haven't seen a response from Julian yet, hope he's accommodating this
    in rev07!
    
    Thanks.
    --
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    >
    >Mallikarjun,
    >
    >> Comments?
    >
    >Hmm.  Ok, I agree.
    >
    >For example, I never really thought:
    >
    >>       0x02 - Delivery Subsystem Failure
    >
    >was the right way to report in-band integrity errors.  Delivery
    >subsystem failure usually means something that is not even detectable
    >by the target, like a timeout.  As such, I agree that the target
    >shouldn't be responding this back.
    >
    >Yes, I have seen many FCP targets do exactly what you're suggesting
    >here.  In fact 0xB 0x4700 (good ole SCSI parity error) is code for
    >many different protocol errors which are detectable and attributable
    >to a particular SCSI command.  For example, bogus settings of FCP
    >F_CTL bits.
    >
    >So, assuming that Target Failure, Delivery Subsystem Failure are all
    >attributable to a SCSI command, I agree they should create CHECK
    >conditions.
    >
    >The place where response values are justified is if the error is
    >attributable to something other than a SCSI command, such as a task
    >management function.  For example, task management function rejected
    >(which we don't seem to have).  If we were anticipating any of these
    >as a response to task management, they should remain, or perhaps we
    >should define new, more specifically task management related responses
    >codes.
    >
    >I'm not clear on what you're proposing for SNACK rejected, but, since
    >it's not CHECK CONDITION, I'm sure whatever you have in mind is fine,
    >but we need to document it better :^)
    >
    >Steph
    >
    
    ------------------------------------------------------------------------------
    
    
    
    >Steph,
    >
    >That is an interesting change in opinion. When I suggested the same thing
    >some releases ago for the same set of reasons
    >(I even suggested avoiding the response codes at all!) as there is no
    >noticeable difference in handling the heat of your response was felt at
    >6000 miles.
    >
    >However I am not sure anymore that given the need for a clearing action for
    >most of those cases that we should not keep
    >the treatment within the iSCSI layer and create an
    >iSCSI-exception-condition (for all iSCSI created responses) cleared through
    >an iSCSI task management function (clear-iSCSI-exception) and reject all
    >intervening commands.
    >
    >This type of handling will let us build independent of SCSI and keep the
    >layering purists happy.
    >
    >Regards,
    >Julo
    >
    
    
    


Home

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