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. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
