Re: [Bug-ddrescue] Suggestion to improve recovery rate during splitting phase.

[kwb78]

Hi Antonio,


Antonio Diaz Diaz wrote:
> 
>>Optimality has more than one dimension. :-)
> 
> Yes indeed. Perhaps the answer is to increase the options for configuring
> ddrescue so people can tune it according to their own priorities.
> 
>>Ddrescue 1.14 skipped after a minimum of 2 consecutive errors, but this 
>>produced logfiles too large (see the point 4 mentioned above). The 
>>algorithm of ddrescue is a compromise between splitting first the larger 
>>areas and keeping logfile size under control. Of course this compromise 
>>can be improved.
> 
> Understood, however given that we are dealing with drive images which are
> often many hundreds of gigabytes in size, a larger log file wouldn't be a
> problem in most cases. I guess the worst case scenario would be that the
> log file needs to describe every single sector on the drive (alternating
> good and bad) which could produce an enormous file, but I think it pretty
> unlikely that situation would occur. Your suggestion of a flag to set a
> maximum file size would work well I think.
> 
>>There are no such areas. After trimming, all non-split areas are flanked 
>>by bad sectors, or else they would have been fully copied or trimmed out.
> 
> That is interesting, because that is not what I am seeing with the drive I
> am working on at the moment. Here is a sample of the log:
> 
> 0x31746F5000  0x00001000  -
> 0x31746F6000  0x029A8600  +
> 0x317709E600  0x06E5D000  /
> 0x317DEFB600  0x00001000  -
> 0x317DEFC600  0x0DCBB200  /
> 0x318BBB7800  0x00012600  -
> 
> As you can see, there is a good area immediately followed by an unsplit
> area. This situation occurs many times throughout this log. If I manually
> edit the current position to 0x317709E600 and start ddrescue it
> immediately starts copying good data until it reaches the bad block where
> it slows down again.
> 
> Here is another section of the same log, but with the unsplit section
> immediately before the good section:
> 
> 0x1F442B000  0x00003400  -
> 0x1F442E400  0x07261A00  /
> 0x1FB68FE00  0x0A8BF200  +
> 0x205F4F000  0x00002000  -
> 
> If I manually set the current position to 0x1FB68FE00 and set ddrescue to
> start copying in reverse it starts copying good data.
> 
> I have done this repeatedly for the largest unsplit areas on the disk, but
> it isn't really practical to do it for long since it is pretty tedious. No
> doubt someone familiar with scripting (which I am not at all) could knock
> up something to parse the log and do it automatically in conjunction with
> the -T switch or similar.
> 
> I don't know whether the log above is typical or if something has gone
> awry that means trimming has not occurred in the manner that it should. I
> have had to restart the process a couple of times since the drive locked
> up or disappeared from /dev.
> 
> 
>>Thank you for sharing your observations. I'll try to optimize splitting 
>>a little more. :-)
> 
> No problem. Thanks for a very useful piece of software.
> 
> Keith.
> 


-- 
View this message in context: 
http://old.nabble.com/Suggestion-to-improve-recovery-rate-during-splitting-phase.-tp34924021p34932991.html
Sent from the Gnu - ddrescue mailing list archive at Nabble.com.