Wanted: Finished ddrescue logs

[maximus57]

I would like to collect some finished ddrescue log files, and maybe some that were not finished because someone gave up due to it taking too long. The purpose is for testing different ddrescue algorithms on real failure patterns in controlled conditions, with the intention of helping Antonio test and improve ddrescue.

Also, if possible, I would like the drive make and model, as that could help to see what patterns the different drives are likely to make.

Please send your log files, compressed if possible, to maximus57@hotmail.com. Or you can attach them here in a reply.

Scott

[FeRD]

Scott,

I happened to notice your request at an opportune moment, as I'm currently in the process of running a recovery on a very unhappy laptop hard drive. (I came to download ddrutility so that I can generate a domain map with ddru_ntfsbitmap, since it's become clear to me that attempting to let ddrescue cover the entire drive would take weeks.)

I suspect my log so far will either be totally useless to you, or of particular interest for your analysis. It involves not only a fairly messy drive with an astonishing number of small error regions, but it's also the product of a significant amount of "meddling" on my part with the operation of ddrescue.

My desire is to recover as much as possible from the readable regions of the drive, before dealing with the errors. So when ddrescue hit a significant error patch, rather than letting it slowly crawl through that region (at read speeds of only tens or hundreds of kB/sec), I'd typically abort the process. Then, I'd restart it with instructions to skip forward a bit (using -i ###G) and send it on its way again. I've also had it walk backwards from the other end of some of the damaged regions, and at one point it finished everything after the start point I'd specified so it actually started the trimming process on the blocks towards the end of the partition.

Here's a ddrescueview screenshot of what the recovery map looked like at the time this log was captured. Messy, as you can see. The log was already 7809 lines at this point.

As I mentioned, I've since generated a ddru_ntfsbitmap domain map to drive the rest of the recovery. The addition of the domain map blew the log up to 73K lines, and it's still growing as it continues to work on the drive. However, it'll obviously never be finished-finished; I don't know how or if that would affect your analysis. But, if it'd be useful to you, I can also share the "completed" log after the recovery process has gotten as much as it can off the in-use areas.

The attached rar file contains both the ddrescue log and the hdparm -I output for the drive in question (a fairly old 200GB Toshiba 2.5" SATA model).

[olegkrutov]

BTW to avoid such a handwork you can run ddrescue first time with --no-split parameter to maximally read what can be read leaving gaps of --skip-size bytes size after failed sector, and then you can run ddrescue with parameter --retrim as much times as you wish or while your drive will stay alive :)