This message is from the T13 list server.
On Tue, 12 Mar 2002 13:28:34 -0800, Harlan Andrews wrote: >This message is from the T13 list server. >The more realistic way of implementing ReadLong/WriteLong is as >follows: And this is the algorithm implemented by many drive that still support R/W Long (but I have heard of several variations on this theme so beware!). >1) Report that the drive has only 4 ECC bytes in the ID data >(even if it has 200 ECC bytes). >2) Host does a ReadLong of LBA N. Drive returns data plus 4 ECC >bytes AND SAVES THE REST OF THE ECC BYTES. >3) Host alters some bits of the data and does a WriteLong back to >LBA N ( including the 4 ECC bytes. >4) Drive writes the data and the FULL ECC back to the media. >5) Host does a Read of LBA N. Drive reads the media and returns >an error OR the corrected data. Ahhh... Now here is the problem... What is a host to think if it has flipped only one bit of the data but the drive reports an uncorrectable error? That one flipped bit added to the other "errors" in the PRML read processing might be all that is needed to make an uncorrectable error. What does this prove? And this scheme can not test the other 60 ECC bytes a typical modern drive has. Remember that testing ECC means you must corrupt not only the data bytes but the ECC bytes too. >6A) If an error is returned, the host knows that the data was >uncorrectable, BUT the host also must realize that there could >have been some OTHER error bits in the data which possibly caused >the data to be uncorrectable. Yep. Sounds like testing conditions that have no known valid test result. >6B) If NO error is returned, then the data should be the same as >what the host wrote via the WriteLong command. Yes. But what if the drive implemented my simple algorithm? In this case the result is the same and nothing was tested. >1) They allow the Host to force an error thereby testing that the >error reporting actually works. This also has other uses (as >reported by Raymond Liu.) Unless you have talked to the drive manufacturer you do not know if your Write Long command is adequate to force a real error. >2) They allow the Host to introduce correctable errors and test >that the error correction actually works (i.e. does not >mis-correct). If an error is returned then the assumption is >that there was some OTHER error bit(s) read back incorrectly. >That is also useful information. Again, sounds like "random" testing of something (for the "fun of it") because the test has no single valid result. Is this really a valid test? I don't think so. But then I'm from the "old school" of testing methodology when a test either Passed or Failed. *** Hale Landis *** www.ata-atapi.com ***
