SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Why is ACA optional?



    
    
    Ralph,
    
    That is an interesting argument.
    
    However, now that disks have become more complex and can queue tasks how
    would you
    handle having one task rejected because the queue was full and the next
    (still in flight) accepted because
    some slot became available?
    
    And this might even happen inside the host (possibly a large SMP) that with
    SMP would not have to care coordinating tasks but without ACA will have to
    strictly serialize access.
    
    IMHO TODAY not mandating ACA is a mistake (IBM 360 disk controllers had it
    30 years ago for the very reason I quoted).
    I any case iSCSI can do little to ease the pain - except to point out to
    those that plan using disk subsystems without ACA to rely on status
    numbering and issue commands one by one.
    
    Regards,
    Julo
    
    Regards,
    Julo
    
    Ralph Weber <ralphoweber@compuserve.com> on 27/11/2000 21:29:46
    
    Please respond to ENDL_TX@computer.org
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: Why is ACA optional?
    
    
    
    
    About two weeks ago, Julian asked:
    
      "I don't see why does T10 not mandate ACA for all (new) devices."
    
    I've been a little busy and apologize for not answering sooner.
    
    The short answer is:
    
      Because disks don't need ACA.
    
    T10 is a pretty disk-centric and the fact that disks can operate
    just fine without ACA is sufficient reason not to mandate it.
    
    Elaboration and explanation of the short answer follow.
    
    In the typical disk I/O case (reads and writes) the results of
    one command have no effect on another command.  So as long as
    autosense returns the sense data with the CHECK CONDITION status,
    there is no need for an error on one command to affect the
    processing of other commands.
    
    Here is an example.  Suppose a program is reading 10 blocks
    and has issued 10 concurrent reads to do the job.  If one of
    the reads fails, the other reads are still good and the problem
    can be corrected by retrying the one failed read.  An almost
    identical case can be made for writes.
    
    Suppose that two unrelated programs are reading their separate
    MSword documents from the same disk.  If one of the reads fails
    there is no reason to stall or fail the reads for the other
    MSword incarnation, just as there would be no reason to fail
    any other reads.
    
    The exceptions to this 98% of the cases fall into two categories:
    
      o Issues that can be (and long have been) punted up to the
        application
      o Very rare cases
    
    In the punt category, the most obvious case is: "What about
    when one application writes a block and another reads it?"
    The punt here is a long standing rule that if a read is
    sent concurrent with a pending write for the same block,
    the disk is free to satisfy the read with either the
    before-write or after-write data.
    
    If the writes and reads are for multiple blocks, the disk
    is further allowed to put some before-write and some after-
    write blocks in the read buffer.  Punt: applications that
    care about concurrent write and read operations had better
    manage the coordination themselves.
    
    It should also be noted that many disk error cases will
    naturally result in the same errors being reported to
    both writes and reads.  One way or another, ACA is not
    required by disks for read/write error handling.
    
    In the rare category, there's the question of "What happens
    is the media is removed?"  This is a non issue because
    most disks are fixed media and if you remove the disk
    you also remove the target, which in iSCSI terms means
    you have to login again.  If you're building a removable
    media disk (the less than 2% case), then you can implement
    the optional ACA or devise some other protection.
    
    These are the reasons T10 has not mandated ACA and it not
    likely to anytime soon.
    
    Thanks.
    
    Ralph Weber
    
    
    
    
    
    
    


Home

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