Re: System lost power in middle of rescue - could image be corrupt?

[Antonio Diaz Diaz]

Shahrukh Merchant wrote:
> I know that if I abort this with Ctrl-C I can resume where I left off by
> re-running the command with no problem since the program has a chance to
> complete pending writes, etc., before stopping. But what if there is an
> abrupt power-off with no warning (no hibernation, no suspend, just
> instant loss of power to the computer and hence the external drive too)?
> No chance to complete cached writes, certainly not to close file handles,
> much less unmount the drive. I don't even know what the drive does in
> such cases with its internally cached but unwritten data.

I have no idea what each drive does in such cases. All I can say is that 
ddrescue fsyncs the output file before writing the mapfile, as you can see 
in line 144 of mapbook.cc. I remember vaguely that on some systems fsync 
does nothing, so you can't be sure if the data reached the medium or not.


> Since it was a 12 hour process for a 2 TB drive that was about 76%
> through, I didn't want to restart it from scratch. Does ddrescue
> guarantee non-corruption in these cases if I just restart it?

Ddrescue can't guarantee that outfile and mapfile agree unless the kernel 
and the drive guarantee the correct sequence of fsyncs. I.e., that if any 
data written after the fsync reaches the medium, then all the data written 
before the fsync must have reached the medium.


> Would it have made a difference if I hadn't used the -d option for
> direct  writes to the hard drive?

The right option is -D, not -d. It could have made a difference if you had 
used it:
http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue

-D
--odirect
    Use direct disc access to write to outfile, bypassing the kernel cache. 
(Opens the file with the flag 'O_DIRECT'). Sector size must be correctly set 
for this to work. Not all systems support this.

    If your system does not support direct disc access, ddrescue will warn 
you. If the sector size is not correctly set, a write error will result and 
no data will be rescued. Some OSs have a bug that prevents them from 
detecting write errors properly (or at all) on some devices if direct disc 
access is not used for outfile.


> In this case I decided to use the mapfile.bak file the second time
> around, since it had a 2 minutes earlier last-modified time than mapfile,
> so it was cheap insurance, but was even that necessary?

Sure it was a good idea. 2 minutes are nothing, and they almost guarantee 
that the data cached corresponding to mapfile.bak reached the medium unless 
the caches are huge or the drive does funny things.


Best regards,
Antonio.