Re: iSCSI: Why is ACA optional?

[julian_satran@il.ibm.com]

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