[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Slowness during recovery

From: Antonio Diaz Diaz
Subject: Re: [Bug-ddrescue] Slowness during recovery
Date: Tue, 23 Dec 2008 18:36:47 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

James W. Watts wrote:
I can't help but feel that this could have been prevented if there were some way to make ddrescue jump past large chunks of bad spots. I thought that was how ddrescue was supposed to work. Instead, I just experienced ddrescue bogging down at the first bad sector(s) it encountered. And there it remained until the drive gave up and died completely.

Really, what could I have done differently? Please educate me.

This is your logfile:
0x00000000  0x617DC000  +
0x617DC000  0x00004400  *
0x617E0400  0x00000200  -
0x617E0600  0x00010000  *
0x617F0600  0x00000200  -
0x617F0800  0x00020000  *
0x61810800  0x0727F800  +
0x68A90000  0x00000C00  *
0x68A90C00  0x00000200  -
0x68A90E00  0x00010000  *
0x68AA0E00  0x00110000  +
0x68BB0E00  0x2E2B285200  ?

The lines marked with '*' are the chunks skipped by ddrescue after every bad sector found. As you can see ddrescue skipped a total of 256KiB after the 3 bad sectors found, and it found good data efficiently.

You could have tried -d (direct disc access), a raw device, or a small value for -c, To check if readahead or kernel caching were slowing it.

If you know the data you want is not at the beginning of the drive, you could have instructed ddrescue to begin reading at the correct place.

You could have restarted ddrescue after the first error, because the drive or the kernel can slow down persistently after the first error.

You can still try the freezer.

But even if you did all this and ddrescue found good data efficiently, there is always the possibility that the drive dies before all the data can be read from it. Sorry.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]