SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI ERT: handling for iSCSI response codes



    
    
    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
    
    Stephen Bailey <steph@cs.uchicago.edu> on 14-06-2001 05:42:09
    
    Please respond to Stephen Bailey <steph@cs.uchicago.edu>
    
    To:   cbm@rose.hp.com
    cc:   Julian Satran/Haifa/IBM@IBMIL, someshg@yahoo.com,
          venkat@rhapsodynetworks.com, ldalleore@snapserver.com,
          Black_David@emc.com, John Hufferd/San Jose/IBM@IBMUS,
          kalman_meth@il.ibm.com
    Subject:  Re: iSCSI ERT: handling for iSCSI response codes
    
    
    
    
    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
    
    
    
    


Home

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