On Mon, Apr 12, 2010 at 4:17 PM, Harry Putnam <rea...@newsguy.com> wrote: > If its possible to add a mirrored set as a vdev to a zpool like what > seems to be happening in (3) above, why wouldn't I just add the two > new disks as mirrored vdev to z2 to start off, rather than additional > mirrors, and never remove the original disks of z2.
I started writing it, assuming that you'd discard the original two drives, then realized you'd said you were going to add the new drives and keep the old but I didn't clean things up completely. What that, the process is: 1. Add the new drives as a mirror vdev to the z2 pool. ( zpool attach z2 mirror new_disk_0 new_disk_0 - The "mirror is very, very important. Without it you'll add two unmirrored vdevs. zpool should complain if this is the case though.) 2. Do a zfs send of all datasets from z3 to z2. 3. zpool destroy z3. 4. Add the drives from z3 to z2 as a mirror vdev. As Daniel suggested, testing the process on VirtualBox / VMWare / etc is a great idea. >> If you're so inclined, you could move some datasets from rpool to z2 >> to keep your rpool smaller. > > So having some data on rpool (besides the OS I mean) is not > necessarily a bad thing then? The pool will resilver faster if it's got less data on it, which may be important to you. The rpool only supports mirrored redundancy, and you can't add more vdevs to it, so the ability to grow it is limited. It's also good practice to keep your OS install separate from your data for maintenance reasons. For my home server, the rpool contains only the OS install and everything else is in a separate pool. -B -- Brandon High : bh...@freaks.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
