Maximum read errors <32> reach at ... when creating support log

[J]

The logfile DP.txt is 367mb. Is there some way I can cull relevant parts for you?

Nevermind that. It will be all read error notifications. The fact that the log is this big means the disk is dying.

Darn! I think this is the logfile from the 1st pass. Grr, I should have made a copy of it. The 300mb+ file is gone now. Probably overwritten. The 1st pass was probably completed on the 1st Mar, 5 pm plus, if I were to convert to my time zone from the time I posted the above reply. There are still some .lo(number) files on the thumbdrive dated on the 1st Mar. I'm not sure if they'll be useful, hopefully they'll be! I'm sending to your email.

I am becoming more and more curious what type of read errors we encountered.

This is interesting. Is it possible to infer from the kind of errors how the disk failed? Say if it's bad sectors caused by vibrations making the disk head scratch the platter, the read errors shouldn't fluctutate much like this?

In my experience (from my systems management days) it's the vibrations that kill, not the temp.

This reminds me of what Tom said about vibrations. I'm curious. Tom, by vibrations I believe you don't mean accidental bumps etc to the chassis right? Do you then mean vibrations caused by the way the hard disk is mounted onto the rack? Like how the direction of casings these days seem to be going towards toolless mounting and they don't seem to be as firm as being mounted on with screws directly.

[Joep]

Hello jay,

For starters: I am convinced that heat kills disks. I think that heat is an issue that should be addressed. 32 degrees celsius environment temperature is a lot. Without knowing the specifics about a disk I'd say you do not want a disk to get hotter then 55 degrees celsius, specially for longer periods of time.

Vibrations may cause failures: Light vibrations may result in higher seek times. The stronger the vibration (upto a shock) the higher the chance that a read head touches the disk surface which will result physical damage.

I got the log files, none of them contains the read errors we see during cloning. I guess if we really want to know what they are we need to read the bad disk again. Basically a read-only surface scan that you stop as soon as it starts hitting read errors would be enough. The pass 2 you tried last time didn't report read errors?

The read errors I am curious about for no particular reason. Sometimes it helps to just look at things without knowing what to expect. That being said: The type of read error will not reveal a cause with 100% certainty but could indicate the severity of the problem. A CRC type error means the contents of a sector are corrupt and they can become corrupt for a number of reasons, the sector itself may be 100% reliable. An 'address mark not found error' is on the other hand much more serious. And we could also see if the resets succeed or fail. if they fail anyway we might as well disable them. So the error specifics may be useful.

Say if it's bad sectors caused by vibrations making the disk head scratch the platter, the read errors shouldn't fluctutate much like this?

Fluctuate like what?

[J]

The pass 2 you tried last time didn't report read errors?

The first time I tried and aborted, it reported read errors the moment it commenced. The second time it only reported read errors about 8% through, it's about 1 tenth of the total sector count. I can't remember the exact number.

Say if it's bad sectors caused by vibrations making the disk head scratch the platter, the read errors shouldn't fluctutate much like this?

Fluctuate like what?

Fluctutate in the sense mentioned above. I encountered them head on immediately in pass 2 the first time, but only after 1 tenth thru the second. Safe to assume that its at diff places?

Since I've already encountered read errors in the clone now, is it possible to pause it and copy off the logfile for you?

[Tom]

Yes, send the log.

[J]

Done.

[Joep]

Hello,

It is the weirdest thing I have ever seen, we get an error back on READ that should never happen on read: a WRITE error. Only thing I can think of the is the disks firmware being corrupt causing it to fetch the wrong error return. Or maybe a firmware bug. Disk resets fail so you may as well disable that, it will probably save you some time. or the BIOS itself, which sits in between DiskPatch and the disk.

In the log you have sent from sector 79623296 it starts throwing this weird error at as, and it continous doing so for 1000s of sectors until you stop the scan. Do you remember how many BLOCKS DiskPatch skipped, how many read errors during pass 1? I am starting to get the feeling that after block 79623296 it does not read anything. A hunch more or less supported that the iRecover screen you posted stops reporting any data or file system structures (all the white blocks) after a certain point - good thing you posted that screen dump.

Try that surface scan again, but be sure to disable the disk reset. If that does not work or change a thing then ...

You could try if iRecover reads beyond that point: by running simple recovery mode (disable the quick scan though: advanced settings > common file system analysis TAB). Set retries to zero and timeout to 200ms. Now if it gets further than http://www.box.net/shared/8sz8ek6861 then let it continue and see if you can get your data that way. I am suggeting iRecover since it uses a different way of accessing the disk than DiskPatch so maybe we have more luck that way.

If that fails I see no other option than sending the disk to a data recovery lab or take the loss.

[J]

Joel, thanks for your reply.

It is the weirdest thing I have ever seen, we get an error back on READ that should never happen on read: a WRITE error. Only thing I can think of the is the disks firmware being corrupt causing it to fetch the wrong error return

Corrupt firmware... Man, I say Murphy's law. Whatever you do, it'll still find a way to get you. I'll check up on the BIOS and see if I should reflash the original firmware.

Do you remember how many BLOCKS DiskPatch skipped, how many read errors during pass 1?

I'm sorry, I can't remember . I did not take any photos of the screen during Pass 1.

Now if it gets further than http://www.box.net/shared/8sz8ek6861 then let it continue and see if you can get your data that way.

I doubt iRecover would work as the screen dump was taken after iRecover finished 100% of the full pass. Though it was not with the retries at 0 and timeouts at 200ms.

I'm calling it a day. It has been exhausting, channeling all my spare time on this for a week. Maybe I'll stick to Western Digital in the future. I would like to thank you and Tom for the time and help you've put into this, though futile. A saving grace would be that this is a first you've seen? It's really exceptional to be able to speak directly to the developers of a software, and if anyone asks, this is the place I'll recommend.

I hope you will be able to give me a refund on DP. I'll forward you the invoice by email. After all this, I'm going to invest in a couple of harddisk coolers. http://www.titan-cd.com/2009_WEB/product/showProhdd_en.asp?ProID=230 Three fans and a heatsink, better  be enough...

Thanks and best wishes.

[Tom]

I'll check up on the BIOS and see if I should reflash the original firmware.

We were talking about the disk's firmware. Dealing with that is decidedly more tricky than flashing the BIOS. But look into the BIOS anyway, you never know.

Refund submitted. Some word of mouth would be appreciated, as it's the only reward we take away after what we put in.