Question: Somewhere on the internets I read that gddrescue is superior to dd at least in terms of being able to distinguish between the amount of disk reads performed on a troubled sector. Is this really the case?

time dd if=/dev/sda skip=900343967 of=a.bin count=4 iflag=direct conv=noerror,sync

dd: reading `/dev/sda’: Input/output error2+0 records in2+0 records out1024 bytes (1.0 kB) copied, 18.6057 s, 0.1 kB/s3+1 records in4+0 records out2048 bytes (2.0 kB) copied, 18.6707 s, 0.1 kB/s

real ?0m18.672suser ?0m0.000ssys ?0m0.004s

Btw, the direct flag really helps, w/o it I was only able to read 1 sector out of 4 (vs 3/4 with it). However, that noticeably slows the transfer speed down – it is at least about 5 times slower for me: 5MB/s vs 25MB/s without this flag. Anyhow, now for the gddrescue (ddrescue) part..

time ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b /dev/sda b.bin

About to copy 2048 Bytes from /dev/sda to b.binStarting positions: infile = 460976 MB, ?outfile = 0 BCopy block size: 1 hard blocksHard block size: 512 ?bytesMax_retries: 0Direct: yes ?Sparse: no ?Split: no ?Truncate: no

Press Ctrl-C to interruptrescued: ?1536 B, ?errsize: ?512 B, ?current rate: ?53 B/sipos: ?460976 MB, ?errors: ?1, ?average rate: ?53 B/sopos: ?1536 B, ?time from last successful read: ?0 sFinished

real ?0m18.736suser ?0m0.004ssys ?0m0.000s

As shown above, it has taken the exact same amount of time for execution. As expected – same stats: 3/4. However, while I could pad the troubled sectors with 0x00 for dd (conv=sync), gddrescue seems to be missing this functionality? Instead, it just skips the troubled sector w/o writing anything to its position and continues with the next following sector (if I already have data written over that sector in the output file – it will not be overwritten: sometimes that might not be desirable). I’m not sure how will the -t (truncate) option works for a block-device with gddrescue (i guess, it will completely overwrite it with 0x00), but on a regular file it will, as predicted, truncate the whole file w/o doing it only within the offset dimensions (i.e. -o1). So, that is somewhat similiar to dd sync, but far from being the same as it will only mimic identicle functionality IF you are ready to overwrite the whole output device/file.

Although, thanks to the presence of verbose option and the ability to log bad sectors/blocks – gddrescue seems like a better choise. It is important to note, that both of the apps were launched with (pretty much) identical params.

The output of

diff ?.bin

is empty (exit 0), meaning the files are exactly the same.

Now this is the part I DO NOT understand:

dd is slow even on the error-free stuff since it’s doing tiny reads and writes. It spends a lot of time chewing through the erroneous parts of the drive, rather than reading as much error-free stuff as it can, THEN going back to do the hard stuff.

What is that all about? Especially the part “it spends a lot of time chewing through the erroneous parts of the drive, rather than reading as much error-free stuff as it can, THEN going back to do the hard stuff”? It took the same amount of time as shown above (even though i have inspected a very tiny portion of data, but should that matter?).

gddrescue offers the -r switch, which should control the amount of re-reads on a “bad sector”, however, dd seems to be running with the -r0 all along (as it took the same time). So, is this option merely for “post-processing”? What I am getting at, is that originally both dd and gddrescue seem to be running with -r0 and dd does not seem to be chewing through the erroneous parts any more than gddrescue (they both seem to halt on a bad block for 15-18 seconds give or take, so what’s the deal, how is gddrescue faster?)

Also, what is the -D option (use synchronous writes for output file) for? I have not noticed any difference from some of the conducted testing.

Can anyone comment on the whole thing? Thanks.

Answer: I’m not sure how the quoted author came to his conclusion. I’m not debating if he is correct, or not, I just don’t have that experience.

On the other hand, in regards to this statement…

?

gddrescue is superior to dd at least in terms of being able to distinguish between the amount of disk reads performed on a troubled sector.

The real “at least” reason to use gddrescue, is because gddrescue does not truncate output on repeated read/write attempts. ?gddrescue also is fully automatic, in regards to certain read errors that would stop dd.

So the quoted author may be correct, he may not… but the whole statement misses the point of gddrescue.

UPDATE: Detailed differences between dd and gddrescue.

dd conv=noerror, will keep going after an error, but it will just skip the bad block.even adding the sync option will just put zeros instead of skipping. ?If you use dd to do another read using the same output, you will just overwrite/lose anything you recovered previously.

gddrescue, will also keep going after error. ?It can recover a partial yield from a bad block, and will go back and attempt the block sector by sector. gddrescue will keep a detailed error log, with good block, bad blocks, and the sector by sector from any bad blocks. If you attempt to perform the read again, gddrescue will cut off (truncate) and add in any additionally recovered data.

Do keep in mind, even with both tools if a whole block in 100% unreadable. ?You will still get no data from it. ?gddrescue can potentially get more data, if some sectors in the block are remain readable.