SCSI 2 Deferred Errors a

Jim McGrath jmcgrath at mail.qntm.com
Wed Oct 12 10:28:25 PDT 1994


        Reply to:   RE>SCSI 2 Deferred Errors and Medium Scan ASA bit


In practice you can always stack deferred errors - i.e. if you have 4
errors, then just report the first, allow the host some time to do
any recovery, then report the second, etc...  Remember that since the
host never knows when the error actually occured, you only have
to report it in time for it to do something about it.  If the host asks
for the same data with a READ, you should be able to handle it via the
cache.

Note that I do not believe that most hosts implement deferred error
handling well.  Many will just bomb on it.  I suggest that hosts detect
the deffered error, get the LBA from the sense data, then issue a READ
to the drive (getting the data from cache) followed by a WRITE (to
another location in your case).  I would not clear the data from my
cache unless I felt the host had adequate opportunity to do this (since
it may require a lot of higher level software processing, it could be
a while before the error is cleared).

Jim


--------------------------------------
Date: 10/11/94 5:49 AM
To: Jim McGrath
From: Brent Skinner
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