zfs discuss - Feb 2010 - Duplicating a system rpool

I''ve got the new controller and the new system disks running in the 
system, for anybody keeping score at home.

So I''m looking at how to migrate to the new system disks. 
They''re a
different size (160GB vs 80GB) and form factor (2.5" vs 3.5") from the
old disks (I''ve got a mirrored pool for my old rpool).

Here''s what I''ve started:  I''ve created a mirrored
pool called rp2 on
the new disks, and I''m zfs send -R a current snapshot over to the new 
disks.  In fact it just finished.  I''ve got an altroot set, and 
obviously I gave them a new name so as not to conflict with the existing 
rpool.

I probably lost properties in the zfs send/receive (111b doesn''t
support
-p on zfs send).   I suppose I could boot from a LiveCd of something 
more recent and re-do the send/receive with a version that supports -p, 
to save me trouble later reconstructing the properties.

So, I was thinking I could reconstruct the properties, rename the pool 
and filesystem (possibly by booting from a livecd), and put Grub on them 
the same way you do when adding a mirror disk to rpool.   Other 
possibilities seem to include using dd to copy one drive physically and 
then booting from it and proceeding from there, and installing from 
scratch on the new drives (and then having to recreate my configuration 
down to UIDs and GIDs manually).

So does anybody have strong opinions about the best, meaning easiest, 
way to do this, remembering that when done I need to import my existing 
data pool and have the user still have access to their data?

I haven''t actually investigated if the bios can boot from the new 
controller, but if not I can finagle the cables around to put the new 
disks on the old controller.

Speaking of which, to make the controller card physically fit I had to 
remove the end bracket from it, since it didn''t match up with the 
cutouts in the back of the case.  This leaves the controller almost 
hanging free (currently supported by an inch of gaffer''s tape), with
one
now and soon two rather stiff SAS-to-4-SATA cable sets connected to it.  
This seems like a bad idea, really.  I suppose I could glue some wood 
blocks to the back of the chassis (or the next covering strip down) to 
provide something solid for the card to rest on, but being restrained in 
both directions seems better.  How do people handle this?  And how did 
this particular standard come to have competition?

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Tue, Feb 16, 2010 at 10:33:26PM -0600, David Dyer-Bennet
wrote:
> Here''s what I''ve started:  I''ve created a
mirrored pool called rp2 on
> the new disks, and I''m zfs send -R a current snapshot over to the
new
> disks.  In fact it just finished.  I''ve got an altroot set, and  
> obviously I gave them a new name so as not to conflict with the existing  
> rpool.
>
> I probably lost properties in the zfs send/receive (111b doesn''t
support
> -p on zfs send).   I suppose I could boot from a LiveCd of something  
> more recent and re-do the send/receive with a version that supports -p,  
> to save me trouble later reconstructing the properties.
That would be handy, but be careful that rp2 isn''t created with a
newer pool version than what you''re copying to it can use (ok, since
you already created the pool).  

Booting from a livecd also allows you to export both pools, then
import rp2 as "rpool" before exporting it again.  That way, when you
boot, it will have the name "rpool".  This is mostly important for the
name of your swap zvol, but is handy if you prefer to keep things just
the same as before.
> So does anybody have strong opinions about the best, meaning easiest,  
> way to do this, remembering that when done I need to import my existing  
> data pool and have the user still have access to their data?
Look at the "root pool recovery" processes document I referred to just
this morning.

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100217/4072f135/attachment.bin>