On Sat, Apr 10, 2010 at 06:20:54PM -0500, Bob Friesenhahn wrote: > 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.
Ah, right you are. D'oh. > The main risk here is that there is only single redundancy for a while. You mean single copy, no redundancy, but otherwise yes.. perhaps that's why I hadn't noticed this scheme, but it was a subconscious oversight. I'd rather consider and eliminate it consciously if so. For Harry's benefit, the recipe we're talking about here is roughly as follows. Your pools z2 and z3, we will merge into z2. <diskx> and <disky> are the current members of z3. Break the z3 mirror # zpool detach z3 <diskx> Add a new vdev to z2 # zpool add -f z2 <diskx> The -f may be necessary, since you're adding a vdev with different redundancy profile to the existing vdev. Replicate the z3 data into z2 # zfs snapshot -R z...@move # zfs create z2/z3 # zfs send -R z...@move | zfs recv -d z2/z3 Free up the second z3 disk and attach as a mirror # zpool destroy z3 # zpool attach z2 <diskx> <disky> Again, commands are approximate to illustrate the steps; in particular you might choose a differnet replication structure. -- Dan.
pgpqZBmWn0joT.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
