11

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
Finished

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.

Community
  • 1
XXL
  • 1,469
  • 4
  • 20
  • 34

2 Answers2

6

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.

J. M. Becker
  • 633
  • 6
  • 15
  • 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. – J. M. Becker 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
  • 1
    @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
  • @Chris Thompson - frankly speaking, the advantage over **dd** seems to be practically non-existant in terms of recovery, if the same **block size** is used. It can only do it faster, if the amount of sectors per operation is higher than the block size. This amount is called a **cluster** by **gddrescue** (-cX). So, the advantage is speed (by default, **gddrescue** uses a cluster size of 128 sectors), but additional stripping (when cluster size is reduced up to the minimum block size [single sector]) in post-mode **might** take even more time, than a **dd** run alltogether - due to an UNC delay – XXL Oct 19 '11 at 21:41
  • @Chris Thompson - the problem is the delay in encountering a non-readable block (UNC), for me it is at least about 10-15 seconds. **gddrescue** will deal with these delays for the same sector **at least** twice (first on the regular run, then in post-mode during inspection). So, if the drive has many bad sectors - you can see the issue, it might take even substantially longer than a **dd** run, even though **gddrescue** would be able to speed things up because of the **cluster** size (but that might not even help overall time wise, because of the aforementioned detail). – XXL Oct 19 '11 at 21:50
  • @XXL, Where are you speaking from? Experience regarding attempted recoveries? It obviously seems you are well researched on dd, what is (if any) your affiliation to coreutils? gddrescue, is so similar to dd, because it is based on dd. Also these projects change over time, dd has been improved since the conception of gddrescue. (As I understand). IF gddrescue has no more relevant value, currently as of today, you would be better served presenting that information in a different medium. As your not really asking an answerable question. (not by anyone other than gddrescue mail list.) – J. M. Becker Oct 20 '11 at 14:21
  • @XXL, Your speaking to someone who is not a gddrescue maintainer (I'm a Linux Sysadmin). By nature, I read information presented by the community, developers and other sysadmins. Pragmatically speaking, I use that information in my work. Your presenting new research, looking at the situation in this new time period. I'm not saying your correct, or incorrect. I could not be expected to, and neither could any general Q & A community. possibly a forum, but really you should post a blog and communicate with the gddrescue maintainers. – J. M. Becker Oct 20 '11 at 14:33
1

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 grc.com 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 grc.com 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 grc.com, 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: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd

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: http://www.myfixlog.com/fix.php?fid=21

Tom
  • 108
  • 2