On Sat, Apr 10, 2010 at 02:51:45PM -0500, Harry Putnam wrote: > [Note: This discussion started in another thread > > Subject: about backup and mirrored pools > > but the subject has been significantly changed so started a new > thread] > > Bob Friesenhahn <bfrie...@simple.dallas.tx.us> writes: > > > Luckily, since you are using mirrors, you can easily migrate disks > > from your existing extra pools to the coalesced pool. Just make sure > > to scrub first in order to have confidence that there won't be data > > loss.
You know, when I saw those words, I worried someone, somewhere would interpret them incorrectly. The migration he's referring to is of disks, not of contents. The contents you'd have to migrate first (say with send|recv), before destroying the emptied pool and adding the disks to the pool you want to expand, as a new vdev. There's an implicit requirement here for free space (or staging space elsewhere) to enable the move. Note, also, rpool can't have multiple vdevs, so the best you could combine curently is z2 and z3. > I'm getting a little (read horribly) confused how to go about doing > something like creating a single zpool of 3 sets of currently mirrored > disks that for each pair, constitute a zpool themselves. This would be something like a "zpool merge" operation, which does not exist. > In the case I'm describing I guess rpool will be the only pool when > its completed. Is that a sensible thing to do? No, as above. You might consider new disks for a new rpool (say, ssd with some zil or l2arc) and reusing the current disks for data if they're the same as the other data disks. > Or would it make more sense to leave rpool alone and make a single > zpool of the other two mirrored pairs? Yep. -- Dan.
pgpsuMiotk6Nw.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
