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