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 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:

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,

Reply via email to