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.