This message is from the T13 list server.
Make it happen Jim, make it happen, please! > RE: RE: [t13] future of R/W long >>> McGrath, Jim 03/12/02 07:36PM >>> ... BTW, I actually like the idea of a capability to allow the drive to test the HOST system by injecting errors into the returned stream. It's similar to what we do by forcing errors in drive components. Given the software intense environment today, testing those error paths in the driver stacks makes a lot of sense to me. Jim > Fwd: RE: [t13] my favorite R/W Long implementation >>> Pat LaVarre 03/12/02 03:16PM >>> This message is from the T13 list server. > Not to add any fuel to the fire, but ... ... > 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. Would be wonderful. I've gone looking for this in T10 Scsi but never found it. Services like these sometimes exist inside the host to help notify everyone that a device property has changed e.g. a partition has become not writeable. I've seen vendor-specific implementations in devices, but designed for internal use only: the shipped devices don't include this feature. These devices can also be programmed to burst a chosen sequence of byte counts - otherwise we find that third-party bridges choke over otherwise rare sequences. Pat LaVarre >>> McGrath, Jim 03/12/02 02:50PM >>> 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. ...
