3 May
2007
3 May
'07
7:12 p.m.
Fully concur with your comments below. After I posted
this earlier I though back over what happened and I
realized that it's probably not dd's fault but more
likely to be some sort of oddball driver issue. I
forget the exact symptom of the failure but I think it
was along the lines of dd being unable to read enough
blocks off the input device despite the math/geometry
stuff working out correctly on paper.
-Dave
--- Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 5/3/07, David Comley <david_comley at
yahoo.com>
wrote:
dd also seems to have some
implementation-specifics
baked into it. On Solaris I was completely unable
to
transfer a raw VMS disk image from one drive to
another (identical) one using dd; however the same
transfer worked correctly under Linux.
Hmm... that seems odd. I've worked with dd a lot,
and it's pretty
stupid. It does what you ask it to and pretty much
not anything else.
Could you have been having issues with the sd
driver or with whatever
device you were asking dd to copy to/from? It's not
tough to get into
situations where the device driver is doing things
seemingly behind
your back because of specifics of the minor number
attached to the
/dev/whatever device file and the baggage that
implies. It's
especially important with tape devices (rewind/no
rewind, compression,
etc.), but it's possible to have issues with using
the wrong device
name with disks. If I had to guess, the most likely
place for a
problem would be if the beginning of the device from
dd's perspective
(its "block 0") didn't translate to physical block 0
on the device due
to the driver skipping over some part of the disk (a
few blocks, a
cylinder, etc) masked off for a disk label region or
some other
"reserved use".
I'm not disputing that you had problems, I'm just
trying to come up
with a mechanism for how it happened.
-ethan