> It could also be useful to have the final logfile to see where are the > unrecoverable errors.
Alright, I will try to keep that in mind. If I fail to do that, feel free to remind me, as I would be happy to share. > Yes, but just once as you guessed. Well, it was an "educated" guess ;-) And I've just started running it. Two things I have observed: First, the error count had been at 26460 before and starting the command with -A made it jump to 40691: GNU ddrescue 1.18-pre6 Press Ctrl-C to interrupt Initial status (read from logfile) rescued: 1724 GB, errsize: 276 GB, errors: 26458 Current status rescued: 1724 GB, errsize: 275 GB, current rate: 0 B/s ipos: 56290 MB, errors: 26460, average rate: 6949 B/s opos: 56290 MB, run time: 21.87 h, successful read: 1 s ago Trimming failed blocks...^C Interrupted by user GNU ddrescue 1.18-pre6 Press Ctrl-C to interrupt Initial status (read from logfile) rescued: 1724 GB, errsize: 20839 kB, errors: 40691 Current status rescued: 1724 GB, errsize: 60314 kB, current rate: 0 B/s ipos: 929641 kB, errors: 40696, average rate: 5046 B/s opos: 929641 kB, run time: 8.48 m, successful read: 1.66 m ago Copying non-tried blocks... Not sure why, but it seems like it picked up the wrong number there. It is quite slow right now, but I suppose that is because I had already gone over that area of the drive without the -A option and there aren't any large sectors left in the beginning. Once it does find one of the good sectors, it does seem faster already, though. So overall, it's about the same speed, it just switches between 0 B/s and even hundreds of kB/s at times. The other observation is not strictly for you - but having ddrescueview running on the side and marking everything as non-tried was a little bit of a shocker, because the color for that is a dark gray. For some reason, that looks even worse than the red for the Bad Sectors - like these blocks aren't just bad, they're already dead! Just my two cents, but maybe a lighter color is the better choice here, since we're assuming those blocks to be fresh for checking? -David On Fri, Jan 31, 2014 at 9:55 PM, Antonio Diaz Diaz <[email protected]> wrote: > David Deutsch wrote: >> >> That's what I was hoping! Sending you the image on a separate, >> personal email with the log file next up. > > > Thanks. It could also be useful to have the final logfile to see where are > the unrecoverable errors. > > > >> I'm not too sure about that, actually. When I tell ddrescueview to >> give me the details on each block, it lists the bad sector as 512 >> Bytes, with about 200megs of non-trimmed data around that. Or maybe >> that's what you meant? > > > I calculated the mean error size dividing the total error size by the number > of errors and I guessed there would be large non-trimmed areas. I see in the > logfile that this is true (there are many multi-megabyte non-trimmed areas). > I guess many of those large non-trimmed areas will be read fast with > '--try-again'. > > > >> So would I simply extend my current command to be from now on: >> >> ddrescue -f -n -d -A /dev/sdf /dev/sde logfile > > > Yes, but just once as you guessed. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
