From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 11 16:05:37 2013 Return-Path: Delivered-To: freebsd-hackers@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 ABFD65BA for ; Thu, 11 Jul 2013 16:05:37 +0000 (UTC) (envelope-from linnemannr@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 77C2F1784 for ; Thu, 11 Jul 2013 16:05:37 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so10002822obc.20 for ; Thu, 11 Jul 2013 09:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y6AEZ09ejIzhT0gpGN483fXjXQKoEkJ45Pz5TLPS7yg=; b=wZdBbVs93VgDqlRvNGxLpJQ1a6fOtiuFr2sTr53M5Jrv7/coj8tp2kSJS9bLdzdwne 72AXs729hDlFxNP8wLXVKH0HvoLaQBCk/so68kuPgLNNC0j8T7DaRfO/WCPkK9OyAwGL K8txmLgrAM52vZXfdNweb7o3loD8OhxBCN9Ht8w2zXAOHbhsrs3kxGqRH82Nf65/0ODF aYcZCmUlZUkT4JoIBLWg+1XrcnPc3n68so/KEg9oegERh9AhHau/k51b6kiYpUMwr6RY LsG30GfQQKCwwfASgH3r4cPkcBJTSCVaj37zr9cz+F00U7K0izjOVm0c1EpRSetRNsWF KlLA== MIME-Version: 1.0 X-Received: by 10.60.103.211 with SMTP id fy19mr32069300oeb.103.1373558737106; Thu, 11 Jul 2013 09:05:37 -0700 (PDT) Received: by 10.182.122.97 with HTTP; Thu, 11 Jul 2013 09:05:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 11:05:37 -0500 Message-ID: Subject: Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem From: Reid Linnemann To: Will Andrews Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:05:37 -0000 Will, Thanks, that makes sense. I know this is all a crap shoot, but I've really got nothing to lose at this point, so this is just a good opportunity to rummage around the internals of ZFS and learn a few things. I might even get lucky and recover some data! On Thu, Jul 11, 2013 at 10:59 AM, Will Andrews wrote: > On Thu, Jul 11, 2013 at 9:04 AM, Alan Somers wrote: > > "zpool export" does not wipe the transaction history. It does, > > however, write new labels and some metadata, so there is a very slight > > chance that it might overwrite some of the blocks that you're trying > > to recover. But it's probably safe. An alternative, much more > > complicated, solution would be to have ZFS open the device > > non-exclusively. This patch will do that. Caveat programmer: I > > haven't tested this patch in isolation. > > This change is quite a bit more than necessary, and probably wouldn't > apply to FreeBSD given the other changes in the code. Really, to make > non-exclusive opens you just have to change the g_access() calls in > vdev_geom.c so the third argument is always 0. > > However, see below. > > > On Thu, Jul 11, 2013 at 8:43 AM, Reid Linnemann > wrote: > >> But now we are to my current problem. When attempting to roll back with > >> this script, it tries to dd zero'd bytes to offsets into the disk device > >> (/dev/ada1p3 in my case) where the uberblocks are located. But even > >> with kern.geom.debugflags > >> set to 0x10 (and I am runnign this as root) I get 'Operation not > permitted' > >> when the script tries to zero out the unwanted transactions. I'm fairly > >> certain this is because the geom is in use by the ZFS subsystem, as it > is > >> still recognized as a part of the original pool. I'm hesitant to zfs > export > >> the pool, as I don't know if that wipes the transaction history on the > >> pool. Does anyone have any ideas? > > You do not have a choice. Changing the on-disk state does not mean > the in-core state will update to match, and the pool could get into a > really bad state if you try to modify the transactions on disk while > it's online, since it may write additional transactions (which rely on > state you're about to destroy), before you export. > > Also, rolling back transactions in this manner assumes that the > original blocks (that were COW'd) are still in their original state. > If you're using TRIM or have a pretty full pool, the odds are not in > your favor. It's a roll of the dice, in any case. > > --Will. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >