Allen,
<<
...The hardware verification in the drive will check to see that the data written to the disk is the same as the data the system sent to the disk. But it won't check to see if the data sent was the same as the data on the source drive, will it?
So if the data was read incorrectly in the first place, a hardware verify wouldn't catch that. Thus, it seems as if the user would be better off disabling the Jaz drive's write verification, and using the backup software's verification instead.>>
I see where you're coming from and you do have a point, but...
* "If the data was read incorrectly in the first place," chances are very good that the backup software will compare the same bad data it read to the same bad data it wrote. In other words, it wouldn't re-read the data from the source drive before doing the compare.
* If you don't have a reliable connection (bad cable or bad termination), then your system is going to do all sorts of random things -- including hanging, locking up, and crashing. Nothing is safe. Reading the source twice might give you two different answers, which one is correct?
* Drives with a reliable connection to the computer shouldn't ever transfer bad data, instead it should report an error. It is exceptionally bad form for a drive to return bad data, because the user gets no indication there is a problem. Iomega's drives use an error detection / correction scheme known as Read Solomon ECC (error correcting codes), that make the chances of an undetected data error extremely small. During a write the drive passes the incoming data through an ECC encoder, which generates a code that is extremely likely to be unique for that data. It then writes both the data and the ECC on the disk. If when the data is read, it doesn't generate the same ECC, the drive knows there is a problem, either in the ECC or the data. Using the ECC, the drive is able to correct most problems with the data and/or the ECC. If it is unable to correct the data, it reports an error and refuses to return the bad data.
* With removable media devices the biggest danger is contaminants getting in the way of the drive head during a write. In which case the drive might succeed in writing a portion of the data, but for some reason doesn't notice the problem during the write. However, the mere act of reading the data allows the ECC error detection to kick in. So, the drive most likely doesn't compare the data given it, to what it put on the disk. Instead it reads back what it just wrote to see if the ECC comes out right.
* Allowing the drive to perform verifies means that all your writes to the drive are verified, where having the backup software perform a verify means only backups are verified.
* The drives verify will take significantly less CPU time on a multitasking system, leaving the processor available for other work.
All that aside, I use my Jaz without verification of any kind. I don't feel the need. |
