This message is from the T13 list server.
Not so fast, Hale....I don't believe this. I have never personally OBSERVED, let alone IMPLEMENTED this stuff this way, even when I implemented it! (whoa...what did he say?) :) Write long would NOT HAVE BEEN CACHED, simply put on the surface! Because of the absolutely strange stuff that WON'T FIT into most caching schemes, this is usually handled separately...and also exactly for the reason you mention: returning cached data that doesn't reflect the surface is suicide! As a MATTER OF FACT, if you look at the Microdrive from IBM, I believe that they DO handle read/write long IN TWO FORMS [which if I remember correctly, IBM was always "throwing a wrench" in there somewhere, just to keep follow-on "product copiers" busy, I suppose]. ;) -ron At 11:11 AM 3/12/2002, Hale Landis 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.
