This message is from the T13 list server.
Not to add any fuel to the fire, but READ/WRITE LONG appears to be used today only in three instances: 1) compatibility with old code, especially test code. It is just more difficult for customers to change their 10 year old code that it is for drive makers to continue and support the command. A lot of obsolete commands stay around in products for this reason. 2) to exercise HOST level error recovery by forcing the drive to return an error on a command. 3) to make a block "bad" for some reason, once again really to trigger host software. The latter 2 would be much better served by a command that just allowed the host to ask the drive to return an error in the future under some circumstances (like read of a specific LBA). But history being as it is, it's been easier just for people to limp along with READ/WRITE LONG. As Hale does point out, it is a useless command today for actual drive testing (except to test if you implemented the command itself of course!). Jim -----Original Message----- From: Thomas Colligan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 11:28 AM To: Hale Landis; T13 List Server Subject: Re: [t13] my favorite R/W Long implementation This message is from the T13 list server. Which supplier implements this algorithm or is it fantasy or is it to shift discussion from the topic at hand. Which is, how are the W/R commands being used today. I see responses thus far useful, but then again there is some non-sense as usual. On 3/12/02 11:11 AM, "Hale Landis" <[EMAIL PROTECTED]> wrote: > This message is from the T13 list server. > > > My favorite R/W Long implementation: > > 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 Write to LBA N: everything normal so far. > > 3) Host does a Read Long to LBA N: return the cached data for LBA N > plus four ECC data bytes of random data (whatever is in the Data > register FIFO will do). > > 4) Host does a Write Long to LBA N: execute the command and discard > all data received. > > 5) Host does a Read to LBA N: return the cached data for LBA N. > > Is this a broken drive? No, how can it be broken? The host put data > in LBA N and the drive returned the same data. > > > > *** Hale Landis *** www.ata-atapi.com *** > > >
