SCSI 2 Deferred Errors and Medium Scan ASA bit
skinner at sector.Kodak.COM
Tue Oct 11 05:08:10 PDT 1994
To: Members of X3T10
From: Brent Skinner
Re: SCSI 2 Deferred Errors and Medium Scan ASA bit
My apologies if some of this may be old material or not the place to ask
these kind of questions, but I am a bit confused regarding deferred error
handling. I am attempting to implement SCSI 2 on a WORM optical drive and
have the luxury of a large volatile SCSI buffer. This would enable the
drive to perform write-behind operations by accepting the data from the
host and responding with a GOOD status. It would also allow us to accept
more data from the same host, or data from another initiator as well...to
which a GOOD status could also be returned. Since the data channel will run
slower than the SCSI bus, we could experience a write error long after the
data has been accepted from the host(s). We do not expect to implement AENC,
and thus will have to wait for another command in order to report any error
that could occur.
In the event that there are a lot of retries occurring within the drive
and the SCSI portion was able to buffer the data for, let's say 4 writes
|from the same host, and a fatal write error occurs that causes all 4
writes to fail, the SCSI 2 spec says that only information for the last
write would be expressed in the ensuing sense data. How will the host
know which write died?
What happens if the plug got kicked? The drive will know that it was in
the middle of a write from a particular initiator to a particular address
(from the most recent CDB stored in non-volatile RAM). At power up the
drive could report the deferred error, but the host may think that there
was data correctly written that wasn't.
I see an open loop here that isn't easily closed. Are there any
recommendations as to how to treat catastrophic errors? Since I am defining
a target it may not be my concern, but I don't want to lose a customer's
My second question deals with the ASA bit in the Medium Scan command. It
is a On/Off kind of bit, but the text for this bit in the spec doesn't
appear to support a converse. An ASA bit of zero scans in sequential order.
An ASA bit of one scans for contiguous blocks. These choices do not
appear to be opposites. I would expect contiguous blocks to be in sequential
order. Am I misinterpreting this?
Thank you for you patience in reading this.
Brent Skinner <skinner at sector.kodak.com>
Eastman Kodak Company
More information about the T10