Hi Steve,
> Does this help
> http://adammooz.wordpress.com/2009/07/14/dcfldds-md5-vs-md5sum/
My understanding was that by the time the Linux kernel returns the data
to dd(1), there hasn't been any disc problem. IOW, the drive corrected
the issue itself, either by multiple reads, ECC, or whatever. If the
drive has to give up, it tells the kernel, and the kernel tells dd(1),
e.g. read(2) returns -1 with errno set to EIO.
Sometimes, it seems the kernel will also have multiple goes, but the end
result is the same; no random data, or zeroes, is returned to dd in
lieu of pucker bytes.
That's how dd(1) work, however, it seems dcfldd has options as to what
to do when the kernel says there's a read error, including continuing
through the rest of the drive. And it can vary how that affects the MD5
digest. See
http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=4992
for some of the gory details.
I don't think I'd find myself using dcfldd. I'd not heard of it before.
TBH, I'd use GNU ddrescue(1), package gddrescue in Ubuntu, and its
--direct option to have it image the drive, passing O_DIRECT to the
kernel so it gets out the way. ddrescue tells you when there's bit of
disc that are a problem and skips over them. But then you run it again,
and again, increasing the number of retries until it, hopefully, gets
all the data. It can keep track, between runs, of what's been
recovered. It worked very well when I had a faulty drive to recover.
Older versions don't have --direct but can do the same thing with raw(8)
setting up a raw device for the drive. The documentation is very
useful.
Having got an image, I'd then get a digest for the image file.
Cheers,
Ralph.
--
Next meeting: Bournemouth, Wed 2010-02-03 20:00
http://dorset.lug.org.uk/ http://www.linkedin.com/groups?gid=2645413
Chat: http://www.mibbit.com/?server=irc.blitzed.org&channel=%23dorset
List info: https://mailman.lug.org.uk/mailman/listinfo/dorset
