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

Will Andrews will at firepipe.net
Thu Jul 11 15:59:06 UTC 2013


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.


More information about the freebsd-hackers mailing list