Date: Thu, 11 Jul 2013 11:05:37 -0500 From: Reid Linnemann <linnemannr@gmail.com> To: Will Andrews <will@firepipe.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem Message-ID: <CA%2B0MdpNZ7VdFvLti3zGKjui=_1d7mkP2W3mKGt2uC370CT6MRA@mail.gmail.com> In-Reply-To: <CADBaqmgUEpE1%2BSLoqJpeZhtjACbkptxL_adcSxzNe0rr0%2BQQPQ@mail.gmail.com> References: <CA%2B0MdpMj81=Ct-ZUJ7N-TYO=OCHeEomU4Xa70sFVVoBoyETzkQ@mail.gmail.com> <CAOtMX2gYaxgwnX0y=uDqgP1Fvc2OLXzFfVK2mYraP799g51o_w@mail.gmail.com> <CADBaqmgUEpE1%2BSLoqJpeZhtjACbkptxL_adcSxzNe0rr0%2BQQPQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@firepipe.net> wrote: > On Thu, Jul 11, 2013 at 9:04 AM, Alan Somers <asomers@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@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-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B0MdpNZ7VdFvLti3zGKjui=_1d7mkP2W3mKGt2uC370CT6MRA>