Unix disk copy using dd ?

[David Comley]

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
>