bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Change of pattern after interrupt


From: David Morrison
Subject: Re: [Bug-ddrescue] Change of pattern after interrupt
Date: Wed, 19 Oct 2016 08:51:46 +1100

At 17:47 +0200 18/10/16, Antonio Diaz Diaz wrote:
Hello,

David Morrison wrote:
So instead of getting non-split and bad sectors, I am getting
non-trimmed failures. I am unsure what this means, other than that I
have another 55 hours to go when I thought I had only about 8. :-(

It may be because of the days passed between the two runs. OTOH, the first part looks as if it had been already trimmed. Is ddrescue trimming just now?

What version of ddrescue are you using?
Did you use the same version both times?

I used 1.16 and all I did was to stop ddrescue and shut down, then restart the computer and issue the same command.

This is the top of the log file:

# Rescue Logfile. Created by GNU ddrescue version 1.16
# Command line: /usr/local/bin/ddrescue -n --force /dev/disk2 /dev/disk1 ./Louise.log
# current_pos  current_status
0xC4462E0000     ?
#      pos        size  status
0x00000000  0x139C0000  +

This seems to indicate it is still doing non-tried blocks.

0xC4462E0000 according to my calculations is 803GB. (This is probably where I stopped it - earlier I said 750GB.)

The last few lines of the log file are:

0x99A2760000  0x3C0620000  +
0x9D62D80000  0x00010000  *
0x9D62D90000  0x00B50000  +
0x9D638E0000  0x00010000  *
0x9D638F0000  0x00090000  +
0x9D63980000  0x00010000  *
0x9D63990000  0x14924D0000  +
0xB1F5E60000  0x00010000  *
0xB1F5E70000  0x1250470000  +   729GB 75GB
0xC4462E0000  0x7FFFFF3BB9D1FFFF  ?

OK, so I realise something that happened earlier might have caused this but I do not understand why. I am glad I keep notes!

At about 274GB, I bumped the power cord and the disk went offline. ddrescue didn't seem to notice this and went on trying all the remaining blocks on the disk. All failed of course and it stopped.

Now when I restarted it, it thought it had already done the whole disk and finished immediately. So I edited the log file to remove the bit after 274GB. I did not think to alter the status line at the top.

So when I restarted it, it continued to copy the rest of the disk as "non-tried", and it was doing that when I stopped it.

What is mystifying is why it did not continue with the non-tried scan from 803GB when I restarted it yesterday. Instead it seems to have switched to trimming from 274GB.

-------------------
Could I make a suggestion which would help to diagnose things like this. It would be useful if ddrescue kept an event log to record significant events. This would include start and stop times together with position and status. It could also include things like when it changes mode, eg, from non-tried to trimming. And the time stamps would be useful in tracking how long each phase took.

This could be a separate file or inserted as comments in the existing log file like this:

# Rescue Logfile. Created by GNU ddrescue version 1.16
# Command line: /usr/local/bin/ddrescue -n --force /dev/disk2 /dev/disk1 ./Louise.log
# current_pos  current_status
0xC4462E0000     ?
# History
# 0x00000000 ? 13-Oct-2016 09:16
# 0x41A4D10000 ? 14-Oct-2016 13:45
# Start trimming 15-Oct-2016 17:34
#      pos        size  status
0x00000000  0x139C0000  +

It may also be useful to add to these lines for when it finishes a scan and changes to a different mode, such as from "non-tried" to "trimming".

Cheers

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]