From owner-freebsd-fs@FreeBSD.ORG Sun Jan 27 14:00:27 2013 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD3958F3; Sun, 27 Jan 2013 14:00:27 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id 37874132; Sun, 27 Jan 2013 14:00:26 +0000 (UTC) Received: from [78.35.163.65] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TzSmQ-0004Q3-NA; Sun, 27 Jan 2013 15:00:18 +0100 Date: Sun, 27 Jan 2013 14:56:01 +0100 From: Fabian Keil To: Ulrich =?UTF-8?B?U3DDtnJsZWlu?= Subject: Re: Zpool surgery Message-ID: <20130127145601.7f650d3c@fabiankeil.de> In-Reply-To: <20130127103612.GB38645@acme.spoerlein.net> References: <20130127103612.GB38645@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/FJX6_h0WkAB0cAJZ1ipHtOB"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: current@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 14:00:27 -0000 --Sig_/FJX6_h0WkAB0cAJZ1ipHtOB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulrich Sp=C3=B6rlein 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--