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