On Sun, 11 Apr 2010, Daniel Carosone wrote:
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.
Since he is already using mirrors, he already has enough free space since he can move one disk from each mirror to the "main" pool (which unfortunately, can't be the boot 'rpool' pool), send the data, and then move the second disks from the pools which are be removed. The main risk here is that there is only single redundancy for a while.
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.
It is nice to have a tiny disk for the root pool. An alternative is to create a small partition on two of the boot disks for use as the root pool, and use the remainder ('hog') partition for the main data pool. It is usually most convenient in the long run for the root pool to be physically separate from the data storage though.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
