[Bug-ddrescue] Fill mode: Program/documentation bug in 1.15-pre1

[Burkart Lingner]

Hi Antonio!

First of all let me thank you for writing ddrescue. It helped me recover 
all of the few bad sectors on one hard drive and most sectors on a more 
badly damaged disk.

As the first disk had only a few bad blocks in the first place I decided 
to write the image back to the disk after recovering all blocks. This 
would prompt the drive controller to map the data from the bad sectors 
to the spare area(s). I went about this by using ddrescue's --fill 
parameter, but unfortunately I encountered two problems.

--- Problem 1: Warnings that are probably erroneous ---

I used the command

ddrescue --fill=+ --force --synchronous image.dd /dev/sdX logfile

which I adapted from the manual, namely example 3 in the chapter on fill 
mode. However, I got this warning:

ddrescue: warning: Options -C -d -D -e -E -g -M -n -p -r -R -S -t and -T
ddrescue:          are ignored in fill mode.

--synchronous equals -D, hence the warning. It turns out, though, that 
data was written at 7 MB/s when I used --synchronous whereas the 
transfer rate increased to 55 MB/s when I omitted it. So I guess 
ddrescue does not in fact ignore -D in fill mode. Therefore the warning 
is misleading. If there is a good reason to actually ignore the 
parameter, the documentation is wrong at this point since it contains an 
example using --synchronous in fill mode.

--- Problem 2: Fill mode writes the same 64 KiB repeatedly ---

After I wrote the image back to disk I discovered that something must 
have gone wrong as the disk did not contain an exact copy. After some 
digging I found out that the first 64 KiB were correctly copied whereas 
all data after that point was differing between the disk and the image 
file. Ultimately it turned out that the first 64 KiB from image.dd were 
repeatedly put on disk, i.e. at offsets 64 KiB, 128 KiB, 192 KiB and so on.

I suspect that this has something to do with how --cluster-size and 
--block-size are configured. I didn't touch the defaults which according 
to the documentation yield a product of exactly 64 KiB.

Personally I assume that this behavior is a bug. Maybe nobody has ever 
tried to write a whole image back onto the drive using fill mode? After 
all, the examples given in the manual all use data less than 64 KiB in 
size, so this might have never been detected by anybody.

If, however, this behavior is intended, then the documentation should 
mention it which it currently doesn't.

Let me know if you need any additional information
Bye, Burkart