SCSI 2 Deferred Errors and Medium Scan ASA bit

Brent Skinner 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
data either.

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 mailing list