On Fri, Jan 9, 2009 at 4:10 AM, noz <sf2...@gmail.com> wrote: > > Here's my solution: > (1) n...@holodeck:~# zpool create epool mirror c4t1d0 c4t2d0 c4t3d0 > > n...@holodeck:~# zfs list > NAME USED AVAIL REFER MOUNTPOINT > epool 69K 15.6G 18K /epool > rpool 3.68G 11.9G 72K /rpool > rpool/ROOT 2.81G 11.9G 18K legacy > rpool/ROOT/opensolaris 2.81G 11.9G 2.68G / > rpool/dump 383M 11.9G 383M - > rpool/export 632K 11.9G 19K /export > rpool/export/home 612K 11.9G 19K /export/home > rpool/export/home/noz 594K 11.9G 594K /export/home/noz > rpool/swap 512M 12.4G 21.1M - > n...@holodeck:~# > > (2) n...@holodeck:~# zfs snapshot -r rpool/exp...@now > (3) n...@holodeck:~# zfs send -R rpool/exp...@now > /tmp/export_now > (4) n...@holodeck:~# zfs destroy -r -f rpool/export > (5) n...@holodeck:~# zfs recv -d epool < /tmp/export_now > > The above is very dangerous, if it will even work.
The output of the zfs send is redirected to /tmp, which is a ramdisk. If you have enough space (RAM + Swap), it will work, but if there is a reboot or crash before the zfs receive completes then everything is gone. In stead, do the following: (2) n...@holodeck:~# zfs snapshot -r rpool/exp...@now (3) n...@holodeck:~# zfs send -R rpool/exp...@now | zfs recv -d epool (4) Check that all the data looks OK in epool (5) n...@holodeck:~# zfs destroy -r -f rpool/export -- Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke My blog: http://initialprogramload.blogspot.com
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
