Date: Sun, 27 Jan 2013 14:56:01 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Ulrich =?UTF-8?B?U3DDtnJsZWlu?= <uqs@FreeBSD.org> Cc: current@FreeBSD.org, fs@FreeBSD.org Subject: Re: Zpool surgery Message-ID: <20130127145601.7f650d3c@fabiankeil.de> In-Reply-To: <20130127103612.GB38645@acme.spoerlein.net> References: <20130127103612.GB38645@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/FJX6_h0WkAB0cAJZ1ipHtOB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulrich Sp=C3=B6rlein <uqs@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... >=20 > 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. >=20 > 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. >=20 > I have: > tank -> sending snapshots to archive >=20 > I want: > tank' -> sending snapshots to archive >=20 > 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. >=20 > 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. >=20 > 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: >=20 > 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"? Fabian --Sig_/FJX6_h0WkAB0cAJZ1ipHtOB Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEFMfgACgkQBYqIVf93VJ11YQCgst43rQ0fEPedB1gaEUIocoQS I/IAni9cEfESXBY5DZOO+mJ44csGHkYN =nniE -----END PGP SIGNATURE----- --Sig_/FJX6_h0WkAB0cAJZ1ipHtOB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130127145601.7f650d3c>