barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (05/18/91)
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.
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. :-)
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!
Dan
//////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett, Department of Computer Science Johns Hopkins University |
| INTERNET: barrett@cs.jhu.edu | |
| COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP |
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (05/18/91)
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
mjr@hussar.dco.dec.com (Marcus J. Ranum) (05/19/91)
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. 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. 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. mjr.
grr@cbmvax.commodore.com (George Robbins) (05/19/91)
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. Given that the partition is self described in the super block and that there are secondary structures on cylinder group basis this is not a reasonable expectatation. The partition is only a container, the filesystem is a structure that may or may not use the entire area. For that matter you can create a "filesystem" structure in places other than disk partitions, though unix may decline to mount the structure and many of the tools are special cased to the point of being broken these days... -- 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)
grr@cbmvax.commodore.com (George Robbins) (05/19/91)
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)
mjr@hussar.dco.dec.com (Marcus J. Ranum) (05/19/91)
grr@cbmvax.commodore.com (George Robbins) writes: >I write: >> >> Using dd to copy filesystems can also be a whole lot slower than >> using dump | restore > >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. Hmmmm... Teach me to post without benchmarking. I've been in the habit of doing the dump | restore thing for years because I have a few cases where it was a HELL of a lot faster stuck in my mind. Not sure why, though, and I guess I'd assumed it was that I wasn't pumping unused blocks over the network. It might have been that the disks were not very full at all. mjr.