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 <w...@firepipe.net> wrote: > On Thu, Jul 11, 2013 at 9:04 AM, Alan Somers <asom...@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 <linnema...@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
