Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 error
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 18.6057 s, 0.1 kB/s
3+1 records in
4+0 records out
2048 bytes (2.0 kB) copied, 18.6707 s, 0.1 kB/s

real 0m18.672s
user 0m0.000s
sys 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.bin
Starting positions: infile = 460976 MB, outfile = 0 B
Copy block size: 1 hard blocks
Hard block size: 512 bytes
Max_retries: 0
Direct: yes Sparse: no Split: no Truncate: no

Press Ctrl-C to interrupt
rescued: 1536 B, errsize: 512 B, current rate: 53 B/s
ipos: 460976 MB, errors: 1, average rate: 53 B/s
opos: 1536 B, time from last successful read: 0 s

real 0m18.736s
user 0m0.004s
sys 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.

share|improve this question

migrated from Oct 18 '11 at 16:56

This question came from our site for system and network administrators.

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.

share|improve this answer
I see, well.. Regarding gddrescue being fully automatic, isn't dd also fully-automatic with conv=noerror? Could you elaborate on the part of "truncate output on repeated read/write attempts"? You mean the "post-processing" stuff, when gddrescue is ordered to re-examine sectors that failed to be read initially? – XXL Oct 18 '11 at 23:59
I updated my answer, to reflect your question. – TechZilla Oct 19 '11 at 16:03
I have used gddrescue a number of times on hard drives and optical media. It's advantage is that it attempts to recover unreadable areas. You can also stop it and re-run it later and it'll pick up right where it left off. – Chris Thompson Oct 19 '11 at 16:10
@TechZilla - gddrescue just skips the bad block as well, just like dd does. Like I have written above, padding with zeros (conv=sync) is the exact option that gddrescue is missing and which is sometimes useful (with extra effort you could do that manually with /dev/zero, because you'd have the log of bad sectors as produced per gddrescue output). There is no difference between gddrescue and dd in terms of recovery, gddrescue does not do anything different in that regard. Why? Because, with the same block size they will recover the same amount of data. – XXL Oct 19 '11 at 21:07
@TechZilla - the only actual difference is when the amount of sectors to process is chosen higher than the block size. This will give you an ability to noticeably speed things up in comparision to dd, as dd can only work with a static non-variable sector size. gddrescue, on the other hand, will first read as many sectors as you have instructed it to, but it will also declare those chunks bad if a single block inside is dubious and once it is done - switch into post-mode inspecting the confusing areas gradually decreasing the sector size until it reaches the minimum block size – XXL Oct 19 '11 at 21:22

Depending on when your hdd was maufactured as well as manufacturer, and what version of firmware it runs, with modern hdds, when bad sectors are detected, they are removed from use by the firmware and the drive knows to skip the bad sectors. So, the notion of "rescuing" a hdd from bad sectors may be moot in that regard. The question of whether the now bad sectors once had valid data seems to be the case solution you are seeking - no pun intended!

There is some software at called spinrite 6 which claims to be able to fix hdds with bad sectors. It is paid software, and I have never tried it. It is worth reading about, especially if one is attempting to "resurrect" a hdd and it actually works as described. The FAQ at regarding spinrite 6 indicates that there is a 30 day money back guarantee (and there is no trial or free version). Note: I am not affiliated with, nor am I recommending it for your situation. I just know it exists and might work as advertised, just don't take my word for it - caveat emptor.

With regard to assessing whether 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, any number of reads on a bad sector (since it is marked as a non-functional sector in a list of bad sectors kept in a firmware list) would not seem to me to be useful in a qualitative use of either gddrescue or dd.

You may find it useful to read the web page, dd (Unix) at:

You might also find it useful to have a look at: How to Create an Image of a Crashed Hard Drive using the UBCD, dd-rescue and P2 eXplorer at:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.