iSCSI: Why is ACA optional?

[Ralph Weber <ralphoweber@compuserve.com>]

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