Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shodha.enet.dec.com!alan
From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.unix.ultrix
Subject: Re: Using "dd" copy copy disk partitions
Summary: dd(1) copies blocks.
Message-ID: <3168@shodha.enet.dec.com>
Date: 17 May 91 23:36:45 GMT
References: <8410@jhunix.HCF.JHU.EDU>
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 35

In article <8410@jhunix.HCF.JHU.EDU>, barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes:
> 
> 	I have used "dd" to copy one disk partition to another over 
> ethernet (dd if=/dev/foo | rsh another dd of=/dev/bar).  Unfortunately,
> this causes the destination partition to believe it is the SAME SIZE
> as the original partition, despite how it was created by newfs.

	Yep, no surprise yet.
> 
> 	I'd like to know if there is a way to convince my destination
> partition of its correct size.  I tried "chpt -d" but that didn't do it.  A
> newfs did it, but of course my data doesn't like that. :-)

	Simple; don't use dd(1).  dd(1) reads blocks from one place
	and copies them to another.  It doesn't care what the blocks
	contain.  You're trying to use dd(1) for something it wasn't 
	designed to do.

	In your case it sound like you're copying the partition table
	along with everything else.  Even if you could enlarge the
	partition, the file system still thinks it was built on a
	smaller disk.

> 
> 	BTW, I know that using dump/restore instead of "dd" would avoid this
> problem.  I'd prefer an after-the-fact fix, not a new method.  Thanks!

	You could use tar(1), but that might pick up other files 
	you don't want.
> 
> | Dan Barrett, Department of Computer Science      Johns Hopkins University |


-- 
Alan Rollow				alan@nabeth.cxn.dec.com