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!
