Date: Thu, 11 Jul 2013 09:59:05 -0600 From: Will Andrews <will@firepipe.net> To: freebsd-hackers@freebsd.org Subject: Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem Message-ID: <CADBaqmgUEpE1%2BSLoqJpeZhtjACbkptxL_adcSxzNe0rr0%2BQQPQ@mail.gmail.com> In-Reply-To: <CAOtMX2gYaxgwnX0y=uDqgP1Fvc2OLXzFfVK2mYraP799g51o_w@mail.gmail.com> References: <CA%2B0MdpMj81=Ct-ZUJ7N-TYO=OCHeEomU4Xa70sFVVoBoyETzkQ@mail.gmail.com> <CAOtMX2gYaxgwnX0y=uDqgP1Fvc2OLXzFfVK2mYraP799g51o_w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADBaqmgUEpE1%2BSLoqJpeZhtjACbkptxL_adcSxzNe0rr0%2BQQPQ>