How to duplicate a HD using dd

[Paul W. Frields]

On Sat, 2003-10-11 at 22:43, jdow wrote:
> > > Actually, I use a slightly different script.
> > > I copy exactly one block starting at block zero. Then I copy the rest
> > > of the logical cylinder skipping the first block on the two disks. Then
> > > I copy by logical cylinders for the rest of the disk, skipping the first
> > > cylinders on the two disks.
> >
> > What script exactly do you use?
> 
> I create it anew each time I need it, I've needed it so infrequently.
> I don't have a copy handy. It's not really beyond mortal ken to figure
> out how to do it if you RTFMP and play with "skip" and "seek" at all
> intelligently. (Gratuitous hint, the first cylinder in the verbal
> script above must be copied with a 512 byte block size for 16064 blocks
> because seek and skip work in terms of blocks.)

Just to throw in my $0.02, for several years I practiced as a forensic
media analyst (and instructor in the science thereof). In general, with
modern IDE drives, you get best results from:

1. Moving the two drives to separate controllers to maximize speed (e.g.
/dev/hda and /dev/hdc);
2. Using a block size of usually 8 Kb - 32 Kb;
3. Making sure that your hdparm -i reports use of UDMA mode (32-bit
access, DMA on, UDMA enabled in kernel) for drives that support it.

The reason simply doing "dd if=/dev/hda of=/dev/hdc" is so slow is that
the kernel block ioctls are written to 1 Kb blocks, while dd defaults to
a 512-byte block size. This means that you have to do two ioctls for
every 1Kb to satisfy the kernel, and that *really* slows down the
process.

You can see the difference in results by simply writing a small test
script and testing a long copy (say, several cylinders worth, or just a
random number of some hundreds of megabytes) with varying block size.
The largest jump in efficiency occurs between 512 byte blocks and 1 Kb
blocks. After that, the differences are significant but smaller up to
somewhere between 8 Kb and 32 Kb for most systems. Using block sizes
much larger than that are usually not effective in speeding the transfer
further.

I've done this literally *tens of thousands* of times, including both in
production phases and scientific testing environments, during my work as
a forensic examiner, using 2.0, 2.2 and 2.4 kernels. Nevertheless, I
would encourage you to test it on your own to verify these results. Good
luck!

-- 
Paul W. Frields, RHCE