Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem

[Reid Linnemann]

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 <will at firepipe.net> wrote:

> On Thu, Jul 11, 2013 at 9:04 AM, Alan Somers <asomers at freebsd.org> 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 <linnemannr at gmail.com>
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>