Certification / disk question

Unless it failed at the very end (the very last sectors), I would say they are not reliable. Write passes are blind so a disk that cannot write is not reliable.

The manufacturer tools are very basic tests, unless they were to take a very long time, at least one or two write passes and read passes.

This is why the certify test is so good. It results in a disk that you know can be written to and read from 3 times without errors. If a disk cannot pass this strenous, but simple test, it is not reliable for important data.

Thank you for the response. Both tests looked like they should take about 5 hours, which is far less than the certify test. The Seagate one was done from DOS, and supposed to be able to "fix" problems, but did not indicate that there were any to fix. I am including two screenshots. The shorter message occurred first. I do not know how far into the tests they occurred because I started them and let them run on their own.

Unless it failed at the very end (the very last sectors), I would say they are not reliable. Write passes are blind so a disk that cannot write is not reliable.

The manufacturer tools are very basic tests, unless they were to take a very long time, at least one or two write passes and read passes.

This is why the certify test is so good. It results in a disk that you know can be written to and read from 3 times without errors. If a disk cannot pass this strenous, but simple test, it is not reliable for important data.

The way to see where the error happened is the SoftRAID log.

Look at the offset where the error occurred. the only times an error is not a disk error is when:
There was a hardware failure (bus/cable, etc.)
The error happens on the last write to the disk. Occasionally we see such errors, we don't know why the drive errors, but if you look at the offset and if it matches the capacity of the disk, you can ask yourself if this was a "bug" instead of an actual error.

Disk write errors usually occur when a disk is on its last legs.

Sorry to hijack this, thread. I have been certifying some 4tb toshiba hdds in 2 thunderbays. The first lot completed okay. But the second lot have come back with errors at the very end
'an error occurred certifying a disk. There was an error verifying data on this disk. The data read back from the disk was different than what was written out.
Disk with error: disk 6, SATA bus 0, ID 6 (thunderbolt), 4TB

3 out of 4, the fourth is finishing in 26 minutes. Is this a problem with the disks, the enclosure (it's in a daisychain - 2nd after the first thunderbay and has a Apple cinema display connected to it. Help please?

If the data was read back inacurately, then there is a problem.

Did this issue happen at the same time, or over time? It is possible it was the cable, or enclosure besides the disks.

recertify them, or try certify one of the "failing" disks on the known good enclsoure, so you have ammunition if you think the enclsoure is faulty.

Disks should not fail a verify pass in a certify. If multiple fail, then I would suspect other hardware, as you are doing.

All 4 new HDDs failed certification. I did them all at the same time.

I'm currently trying again, this time each enclosure to its own thunderbolt port. Another 60 hours to go.

BTW I'm currently trying to copy data from my remaining drives in my USB enclosure to a new drive in the same enclosure. The USB is attached to an OWC thunderbolt dock that one of the Thunderbays is attached to. I'm not sure, but whilst I'm doing this the certify time for *both* the enclosures seems to have gone up. Will USB copy operations affect the certify time in TB enclosures?

USB copies should not affect hte certify times, as even if you are connecting the USB drives through a Thunderbolt dock, you would not be close to the max throughput over Thunderbolt.

Times on certify vary widely, it goes up and down, as disk performance slows as you get further into the disk and faster when you start over. I don't think the change you notice is due to USB file copies.

A quick question: at the default setting, certifying consists of three sets of identical writing and verifying? So if the process fails at the very end, it's basically at the third set of writing/ verifying or is there any 'rounding up' process after the sets of three?

the very end could be the random access test.

A certify pass writes a semi-random pattern across the disk. Then reads it back.
the last pass is all zero's, so the disk is returned to "factory new" condition.

after the certify, a random access test is done, that stresses the disk very heavily, with random read and write I/O all over the disk.