SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iscsi: rev 05 2.5.1 requires ACA support



    
    
    We are aware of the support for ACA missing from some drivers.
    The situation is even exacerbated by the fact that certain exceptions that
    are not errors per-se
    will require ACA to be fired to accomodate for commands in flight (like
    reservations, busy, task-set-full).
    
    However actions at the initiator can be fine-tuned with the NACA bit in CDB
    and the ACA atrribute for the task.
    
    Julo
    
    Black_David@emc.com on 16/03/2001 03:46:29
    
    Please respond to Black_David@emc.com
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  RE: iscsi: rev 05 2.5.1 requires ACA support
    
    
    
    
    > After an error if you have commands in flight you want them all dropped
    > until you specifically reset the ACA and restart the queue (prevent
    things
    > to be executed out of order).
    
    The T10 folks will have to go after this one in more detail, but Julian's
    above statement is correct *only* if the commands in flight depend on
    the one that caused the error (i.e. executing them out of order will cause
    problems).  This is generally not the case for disks where the usual
    practice is to enforce command execution order dependencies
    (e.g., database write ordering) in the operating system and applications
    by waiting for responses (yes it's possible to do better, but lots of
    existing software doesn't).  The result is that commands in
    flight can be executed in arbitrary order with arbitrary ones of them
    failing without causing further difficulties.  As Ralph has pointed out,
    most hosts do not use ACA for disk-based storage, and if iSCSI
    always does ACA, this will cause nasty integration issues.
    
    Just to stir the pot further, I believe Fibre Channel provides a negative
    example, because if FC drops a frame (which is not a good idea,
    but can still happen), the FC component that dropped the frame has no
    clue about what ACA is, or how to get the target (which is not the
    same piece of hardware) to enter ACA state.  Both Class 2 and Class 3
    are vulnerable to this.
    
    Tapes are another matter - do we still have a tape expert on the list?
    
    I thought where we were headed on ACA was something along the
    lines of:
    - Targets MUST implement.
    - Initiators MAY use.
    - Initiator support for ACA is NOT REQUIRED.
    which would imply a text key for Initiators to tell Targets
    whether ACA behavior is expected.  Did I miss something?
    
    --David
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    
    


Home

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