Mark V. Dalton wrote:
I'm hoping that this is simpler than I think it is. :-)

We routinely clone our boot disks using a fairly simple script that:
1) Copies the source disk's partition layout to the target disk using 
[i]prtvtoc[/i], [i]fmthard[/i] and [i]installboot.[/i]

Danger Will Robinson!  Disks can and do have different sizes, even disks with 
the
same (Sun) part number.  This causes difficulties or inefficiencies when you 
blindly
copy the partition table like this.  You will be better off using a script which
creates the new partition map based upon the actual geometry and your desired
configuration.  This really isn't hard, but it does become site specific.  Hint 
use bc.

2) Using a list, runs [i]newfs[/i] against the target slice and [i]ufsdump[/i] 
of the source slice piped to a [i]ufsrestore[/i] of the target slice.

Yep, been doing that for decades.  Actually, cpio is generally easier.

The result is a bootable clone of the source disk.  Granted, there are 
vulnerabilities with using ufsdump on a mounted file system but it works for us.

Actually, cpio is generally easier.

We're now looking at using ZFS file systems for /usr, /var, /opt, /export/home, etc., 
leaving the root file system ("/") as UFS and swap as a bare slice as it is now.

Actually, cpio is generally easier.

I've successfully created an Alternate Root Pool and have replicated the ZFS file systems from another source [i]zpool[/i] into 
the Alternate Root Pool using "zfs send" and "zfs receive".  Right now, I'm doing this without the benefit of 
a bootable system to play with.  I'm experimenting with just ordinary file systems, [b][i]not[/i][/b] "/ufs", 
"/opt", etc.  Now comes the "chicken and the egg" part.

I think I would have to fix-up the mount points of the newly copied ZFS file systems on the Alternate Root 
Pool so that they remain set to "/ufs", "/opt", etc.  By the way, would these file 
systems have to be "legacy" mount points?  It seems like they would have to be.

Here's the part that makes my head hurt: If I've created this Alternate Root Pool on this 
separate disk slice and populated it and exported it and I've replicated a UFS root 
("/") file system on that same disk but in slice 0, how does that zpool get 
connected when I try to boot that cloned disk?

Fundamentally, the question is, how does one replicate a boot/system disk that 
contains zpool(s) for file systems other than the root file system?

This is fairly straightforward with UFS file system technology.  The addition 
of zpool identity seems to complicate the issue considerably.

IMHO, it is more straightforward with ZFS, but I'm biased :-).  For information
see the ZFS boot pages, http://www.opensolaris.org/os/community/zfs/boot/

How far you can go with this today depends on whether you're using SPARC or x86.
 -- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to