This message is from the T13 list server.
I think you're missing the point. For more than a decade ECC fields have been longer than 4 bytes. Basically the READ/WRITE LONG commands have not been valid for their original purpose for at least that long, probably longer. Indeed, I don't think they have been valid since drive manufacturers began integrating the controller onto the drive (i.e. the entire lifetime of the ATA standard, going back to ATA 1). Remember that ATA was a standardization of what was originally a vendor unique interface developed in the days when controller boards and HDDs were separate devices (i.e. the early 80's). At that time such a function make sense. When the two were combined, this original purpose lost its meaning. If anything, the ATA committee is way too slow in obsoleting functions! If people need commands for other things (like error injection to test host software), then maybe a proposal along those lines would be appropriate. Once a command is obsolete, you really should not be depending on it being there going forward. Jim -----Original Message----- From: sraposo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 11:47 AM To: [EMAIL PROTECTED] Subject: Re: [t13] Read/Write Long This message is from the T13 list server. Mr. Landis, I could privately answer to your comments, but since your reply was public to the T13 group, I do this way. >Can you explain why you think you need R/W Long? Do you think it can >be used to read sectors that have uncorrectable ECC errors in hopes >of recovering some of the data (BAD IDEA)? Do you think these >commands actually can test the extrememly complex ECC algorithms used >in today's disk drives (IT CAN NOT)? I think it is healthy to consider that T13 group has many people that doesn't work at a HDD factory, although it is intended to discuss AT/A development, issues, new directions etc. But, there are many professionals that in a way or another is afected by AT/A standard, like me. Answering to your questions, sometimes the only way to get sector data is to read the sector the way that is possible. Reading the sector data field desconsidering ECC or anything else compliance is not the first choice, surely. I am not a HDD maker, but an end user. If a read long command returns me either 4 or more ECC bytes, my first thought is that these ECC bytes are real! Why should I mistrust them? Should I mistrust any other results that AT/A commands return? > >The commands were removed for two reasons... The are ineffective on >today's drives and they have a PIO Data In/Out protocol that was >never documented and is slightly different from the standard PIO Data >In/Out protocol. PIO protocol sure is not the fastest way to move data. Read/Write Long commands did not even handle more then one sector. But, although all these handcaps, read/write long commands are/were sometimes useful. > 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. I guess no one who deals with HDD at low level expects to face such a fantasious performance. If some HDD vendor implement this algorithm, It is clear that it is a very unrespectful treatment to the user!
