We are currently following the forensic suggestion with a no-retry-logged-scan, direct-read-retry-rescan and follow-up retrim direct scans on a failing hard drive. I thought I had a grasp of what the steps were essentially doing.

My assumption was:

1) first scan with no retries was just to grab as much info that was not producing errors as possible, logging those that do for more intensive recovery attempts later.

2) second scan was the first aggressive attempt to go over the error specific sectors logged on the first scan to recover as much as possible

3+) third and subsequent scans with --retrim I 'thought' was going over the remaining list of errors and recovering any still recoverable.

The problem that now has me scratching my head is that upon the third scan, it started with 355 errors listed (I'm assuming from the log). It was doing a good job recovering many of the earlier ones and a few later on after a bad stretch of about 15 minutes where it couldn't recover any. The number reduced down to 285 still early on into the scan. But now the number of errors has risen back up to 296. What is actually going on for this number to go 'up'? I assumed it wasn't attempting to read anything other than those already marked as errors and would only change the error count if it was able to successfully read one already marked as bad. I wasn't expecting to see this number go 'up'. So I must be missing something.



My illustration:

If the error count is 'counting sectors', your conclusion would be correct, but if the error count is 'counting contiguous blocks of one or more bad sectors', and one such block can be split into several blocks, if some sectors inside such a block are recovered as readable but surrounded by bad sectors.:

...GGGBBBBBBBBBBGGG...` (one bad block) -->

...GGGBBBGGBBGBBGGG...` (three bad blocks).

Explanation in info ddrescue:

The total error size ('errsize') is sum of the sizes of all the non-trimmed, non-scraped and bad-sector blocks. It increases during the copying phase and may decrease during trimming, scraping and retrying. Note that as ddrescue scrapes or retries the failed blocks, the good data found may divide them into smaller blocks, decreasing the total error size but increasing the number of errors.

  • cool, ty. We surmised it was something like that – Scott Jan 17 '18 at 18:31
  • @Scott, You are welcome, I'm glad that I could help :-) – sudodus Jan 17 '18 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.