This message is from the T13 list server.
> Should I mistrust any other results that AT/A commands return? I hear you should not expect Seek to move the heads where you asked them to go. Seek is another thing that I hear will die at 128GiB @ 0.5KiB in Ata and at 2TiB in Scsi. You should mistrust any software written by two or more people, of course. Mistrust of read data is part of why RAID has a market - I wonder if RAID folk may have commonly accepted measures of how often the data is flat wrong rather than merely unavailable. If you ask me, Crc over code to be trusted to execute is a Good Idea too rarely implemented. Counting the bytes moved and checking that count against the count you expect is a Good Idea: these counts fail to match measurably often in prototypes, which by definition calls into question how often they fail to match in shipping devices. Pat LaVarre >>> sraposo 03/12/02 12:46PM >>> 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! ...
