This message is from the T13 list server.
In a previous email on this thread, i described how it is possible to make R/W long capable of completely testing ECC. The ways to provide access for testing are only limited by one's imagination and that includes on the interface. Cheap to do as well. Anybody who's going to buy a godzillion drives from a company has a few rights to verify that what they're buying works without a "mistrust" guilt trip being laid on them. Of course, most OEM's would rather have the drive manufacturer's test the drives for them, but often times they provide the software which, in some cases, uses R/W Long. But the big picture point is that these commands should not be obsoleted without a public forum on this reflector prior to their elimination. Furthermore, unless there is a valid reason (and I haven't heard one yet on this reflector) to eliminate them, they should never be eliminated, obsoleted, or otherwise disposed or dropped. That brings to mind the seek command. It seems to me that if the seek command is eliminated, that people with old machines without Windows will not be able to replace their hard drive. There is a reason not to obsolete the seek command. 3/20/02 2:48:22 PM, "Hale Landis" <[EMAIL PROTECTED]> wrote: >This message is from the T13 list server. > > >On Wed, 20 Mar 2002 09:56:59 -0800, Thomas Colligan wrote: >>This message is from the T13 list server. >>So why the two positions? > >With respect to R/W Long there are two positions: a) the old R/W Long >commands are inadequate to test a modern drive's ECC -and- b) due to >a lot of "mistrust" many disk drive customers feel a need to perform >this testing. OK, if a disk drive manufacturer wants this business >then that manufacturer will implement a set of vendor specific >commands to test the ECC of their drive (or even specific model of >drive). Those vendor specific commands might even "look like" the old >R/W Long commands. But in general we have progressed past the days >when commands like those intended to test MFM disk controllers are >adequate. And testing the ECC on modern drive model A may be very >different than testing the ECC on modern drive model B. > >>Everyone, happy except for drive suppliers because they would have to do as >>their customers ask. What a novel Idea? > >But when customer ask for things that make no sense what should T13 >do? The answer is T13 will wait for someone to bring in a proposal >that makes sense. I don't recall a single proposal in the last 4 >years to define a new and better way to do ECC testing from a host. > >>As Harlan stated it is getting harder and harder to test today's ATA hard >>drives for a number of reasons. I expect HDD supplier factories are under >>the same constraints. How do you completely test a 120GB in the time >>required by upper management, and state that the drive is good. We should >>be adding new test technologies that allow for a quicker analysis of drive >>issues. As the capacity of today's HDD increase the more difficult it will >>be for all of us. > >What do you want to test? Many drives have all their hardware logic >and firmware inside a single chip. There isn't much that can be >tested externally with any real confidence. Only the drive can test >itself internally and report the result (isn't that what SMART is all >about?). But I hope everyone knows that a modern disk drive runs a >multitasking "OS" with anything from four to eight tasks, each >responsible for some part of the disk drive's operation. How are you >going to test that? But I'll ask again... What parts of a disk drive >do you want to test (and why)? Lets see the proposal(s). > > > >*** Hale Landis *** www.ata-atapi.com *** > > > >
