Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.unix.ultrix
Subject: Re: Using "dd" copy copy disk partitions
Message-ID: <21710@cbmvax.commodore.com>
Date: 18 May 91 19:58:03 GMT
References: <8410@jhunix.HCF.JHU.EDU> <3168@shodha.enet.dec.com> <1991May18.170358.24367@decuac.dec.com>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 28

In article <1991May18.170358.24367@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
> 
> 	Using dd to copy filesystems can also be a whole lot slower than
> using dump | restore, since dd will copy unused blocks as well as used
> ones, which dump is smart enough to avoid. In the filesystem is 1/2 full,
> dump | restore should be twice as fast as dd'ing the filesystem.

Wrongo!  On any decent sized filesystemm, restore is *much* slower than
dump.  You'd need a better than 2-1 ratio to make your point.
 
> 	I suppose there might be another benfit of using dump | restore
> since the filesystem will have a nice opportunity to lay stuff out in
> rotational proximity.

Optimist.  8-)
 
> 	One thing I can't remember - if you copy the 'c' device with
> dd, don't you also wind up replacing the bad block table on the destination
> disk with the bad block table from the donor? The possible side effects
> of that could be interesting.

Yes, but only with traditional devices that have the bad block information
within the C partition.  These are becoing scarce.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)