Dan Nelson <dnel...@allantgroup.com> wrote: > In the last episode (Jan 28), Fabian Keil said: > > Ulrich Spörlein <u...@freebsd.org> wrote: > > > On Mon, 2013-01-28 at 07:11:40 +1100, Peter Jeremy wrote: > > > > On 2013-Jan-27 14:31:56 -0000, Steven Hartland > > > > <kill...@multiplay.co.uk> wrote: > > > > >----- Original Message ----- > > > > >From: "Ulrich Spörlein" <u...@freebsd.org> > > > > >> I want to transplant my old zpool tank from a 1TB drive to a new > > > > >> 2TB drive, but *not* use dd(1) or any other cloning mechanism, as > > > > >> the pool was very full very often and is surely severely > > > > >> fragmented. > > > > > > > > > >Cant you just drop the disk in the original machine, set it as a > > > > >mirror then once the mirror process has completed break the mirror > > > > >and remove the 1TB disk. > > > > > > > > That will replicate any fragmentation as well. "zfs send | zfs recv" > > > > is the only (current) way to defragment a ZFS pool. > > > > It's not obvious to me why "zpool replace" (or doing it manually) > > would replicate the fragmentation. > > "zpool replace" essentially adds your new disk as a mirror to the parent > vdev, then deletes the original disk when the resilver is done. Since > mirrors are block-identical copies of each other, the new disk will contain > an exact copy of the original disk, followed by 1TB of freespace.
Thanks for the explanation. I was under the impression that zfs mirrors worked at a higher level than traditional mirrors like gmirror but there seems to be indeed less magic than I expected. Fabian
signature.asc
Description: PGP signature
