Re: Zpool surgery

On Sun, 2013-01-27 at 14:56:01 +0100, Fabian Keil wrote:
> Ulrich Spörlein <uqs_at_FreeBSD.org> wrote:
> 
> > I have a slight problem with transplanting a zpool, maybe this is not
> > possible the way I like to do it, maybe I need to fuzz some
> > identifiers...
> > 
> > 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.
> > 
> > So, I have tank (the old one), the new one, let's call it tank' and
> > then there's the archive pool where snapshots from tank are sent to, and
> > these should now come from tank' in the future.
> > 
> > I have:
> > tank -> sending snapshots to archive
> > 
> > I want:
> > tank' -> sending snapshots to archive
> > 
> > Ideally I would want archive to not even know that tank and tank' are
> > different, so as to not have to send a full snapshot again, but
> > continue the incremental snapshots.
> > 
> > So I did zfs send -R tank | ssh otherhost "zfs recv -d tank" and that
> > worked well, this contained a snapshot A that was also already on
> > archive. Then I made a final snapshot B on tank, before turning down that
> > pool and sent it to tank' as well.
> > 
> > Now I have snapshot A on tank, tank' and archive and they are virtually
> > identical. I have snapshot B on tank and tank' and would like to send
> > this from tank' to archive, but it complains:
> > 
> > cannot receive incremental stream: most recent snapshot of archive does
> > not match incremental source
> 
> In general this should work, so I'd suggest that you double check
> that you are indeed sending the correct incremental.
> 
> > Is there a way to tweak the identity of tank' to be *really* the same as
> > tank, so that archive can accept that incremental stream? Or should I
> > use dd(1) after all to transplant tank to tank'? My other option would
> > be to turn on dedup on archive and send another full stream of tank',
> > 99.9% of which would hopefully be deduped and not consume precious space
> > on archive.
> 
> The pools don't have to be the same.
> 
> I wouldn't consider dedup as you'll have to recreate the pool if
> it turns out the the dedup performance is pathetic. On a system
> that hasn't been created with dedup in mind that seems rather
> likely.
> 
> > Any ideas?
> 
> Your whole procedure seems a bit complicated to me.
> 
> Why don't you use "zpool replace"?


Ehhh, .... "zpool replace", eh? I have to say I didn't know that option
was available, but also because this is on a newer machine, I needed
some way to do this over the network, so a direct zpool replace is not
that easy.

I dug out an old ATA-to-USB case and will use that to attach the old
tank to the new machine and then have a try at this zpool replace thing.

How will that affect the fragmentation level of the new pool? Will the
resilver do something sensible wrt. keeping files together for better
read-ahead performance?

Cheers,
Uli