This message is from the T13 list server.

Pat,

Yes, a write command that fails renders all the contents of the blocks it
addresses indeterminate.  The same for your other examples.  This is a
fundamental property of most storage devices and the software (like file
systems) used to manage them.  It has nothing at all to do with the device
interface.

Indeed, how could it be otherwise? HDDs, like Flash and other technologies,
are update in place.  For some period of time EVERY block you update is in
an intermediate (and thus indeterminate) state.  If an non recoverable (at
the device level) error occurs at that time, then you get an indeterminate
result.

Are all the blocks affected by the command indeterminate?  You don't know
unless you know the details of the device design - which is the last thing a
"transparent bridge" should be relying on.  You have to assume everything is
trashed, and the only successful recovery is re issuing the command and
having it complete successfully.

Jim




-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 11:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [t13] significant byte counts other than the total


This message is from the T13 list server.


> Harlan Andrews <[EMAIL PROTECTED]> 12/13/01 05:31PM
> ...
> Neither the device nor the host should use
> ANY intermediate data
> until  the transfer is COMPLETED
> and errors are checked.
> Therefore, the "extra"  bytes should be completely transparent.

Hang on a minute, this can't be meant as quoted out of context here?

An x0A/2A/AA Write block command that fails renders all the content of the
blocks it addresses indeterminate?  Maybe commonly only the blocks before
the bad block changed, but only a BadHost assumes that limited effect?

Ditto a ModeSelect command: a bad page in the stream doesn't guarantee that
good pages in the stream will have no effect?

Ditto a WriteBuffer command: a bad Crc for the last burst of bytes doesn't
guarantee the good bytes sent earlier will have no effect?

Ditto ....

> Neither the device nor the host should use
> ANY intermediate data
> until  the transfer is COMPLETED
> and errors are checked.

A device can avoid using intermediate data only by buffering all the data of
the command.

For a command block that moves, say, xFFFF blocks i.e. about 32MiB at
0.5KiB/block, ... no device that buffers less than 32MiB can avoid using
intermediate data.

Pat LaVarre


Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to