> Cloning disks in that manner is less than optimal.  Garbage may go
> along for the ride.

How does that make it "less than optimal"?

> The best way to clone, I was taught,

I tend to shy away from any "best way" claims that don't include a
consideration of the tradeoffs involved.

> is to

> 1. format the drive if required.
> 2. label with disklabel.
> 3. newfs the file systems needed.
> 4. cyclically dump/restore between the required
>    file systems.
> 5. write boot blocks if needed.

Well, I wouldn't use dump/restore; reading Zwicky's paper has made me
very leery of backup/restore programs that haven't been checked against
her torture test.  (Admittedly, I haven't tried running them on recent
dump/restore.  But I have tried them on a past version of my tar, and
it got things as right as possible.)

That aside, my reactions to your way:

Pro:
	Can change the filesystem size and/or c/h/s geometry.  Doesn't
	copy unallocated blocks; depending on the backup and restore
	programs used, may not copy even unused space in allocated
	blocks.  (This last has not only speed but sometimes security
	implications.)

Con:
	On filesystems near full, tends to be slow, often slower than
	even dd, never mind smart dd-alikes that overlap reads and
	writes.  Mounting the target filesystem async helps some, but
	often not enough to beat a smart dd-alike.  Thrashes severely
	when copying between partitions on the same spindle.  Works
	partition-by-partition, requiring at least a little assist when
	dealing with multiple partitions, even if on the same drive.

If you truly are cloning, as in cranking out cookie-cutter identical
systems for a student lab or some such, the dd (or dd-alike) method
allows you to copy a whole disk, including bootblocks and partitioning,
to an identical disk in a single operation.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B