From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Fixing recursive fault and parent transid verify failed
Date: Tue, 8 Dec 2015 15:25:14 +0000 (UTC) [thread overview]
Message-ID: <pan$73edd$edd83c4d$2a373055$4b6032dd@cox.net> (raw)
In-Reply-To: 20151207195504.GA9262@alistair-xps13
Alistair Grant posted on Tue, 08 Dec 2015 06:55:04 +1100 as excerpted:
> On Mon, Dec 07, 2015 at 01:48:47PM +0000, Duncan wrote:
>> Alistair Grant posted on Mon, 07 Dec 2015 21:02:56 +1100 as excerpted:
>>
>> > I think I'll try the btrfs restore as a learning exercise, and to
>> > check the contents of my backup (I don't trust my memory, so
>> > something could have changed since the last backup).
>>
>> Trying btrfs restore is an excellent idea. It'll make things far
>> easier if you have to use it for real some day.
>>
>> Note that while I see your kernel is reasonably current (4.2 series), I
>> don't know what btrfs-progs ubuntu ships. There have been some marked
>> improvements to restore somewhat recently, checking the wiki
>> btrfs-progs release-changelog list says 4.0 brought optional metadata
>> restore, 4.0.1 added --symlinks, and 4.2.3 fixed a symlink path check
>> off-by-one error. (And don't use 4.1.1 as its mkfs.btrfs is broken and
>> produces invalid filesystems.) So you'll want at least progs 4.0 to
>> get the optional metadata restoration, and 4.2.3 to get full symlinks
>> restoration support.
>>
>>
> Ubuntu 15.10 comes with btrfs-progs v4.0. It looks like it is easy
> enough to compile and install the latest version from
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git so
> I'll do that.
>
> Should I stick to 4.2.3 or use the latest 4.3.1?
I generally use the latest myself, but recommend as a general guideline
that at minimum, a userspace version series matching that of your kernel
be used, as if the usual kernel recommendations (within two kernel series
of either current or LTS, so presently 4.2 or 4.3 for current or 3.18 or
4.1 for LTS) are followed, that will keep userspace reasonably current as
well, and the userspace of a particular version was being developed
concurrently with the kernel of the same series, so they're relatively in
sync.
So with a 4.2 kernel, I'd suggest at least a 4.2 userspace. If you want
the latest, as I generally do, and are willing to put up with occasional
bleeding edge bugs like that broken mkfs.btrfs in 4.1.1, by all means,
use the latest, but otherwise, the general same series as your kernel
guideline is quite acceptable.
The exception would be if you're trying to fix or recover from a broken
filesystem, in which case the very latest tends to have the best chance
at fixing things, since it has fixes for (or lacking that, at least
detection of) the latest round of discovered bugs, that older versions
will lack.
While btrfs restore does fall into the recover from broken category, we
know from the changelogs that nothing specific has gone into it since the
mentioned 4.2.3 symlink off-by-one fix, so while I would recommend at
least that since you are going to be working with restore, there's no
urgent need for 4.3.0 or 4.3.1 if you're more comfortable with the older
version. (In fact, while I knew I was on 4.3.something, I just had to
run btrfs version, to check whether it was 4.3 or 4.3.1, myself. FWIW,
it was 4.3.1.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2015-12-08 15:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 1:57 Fixing recursive fault and parent transid verify failed Alistair Grant
2015-12-07 2:09 ` Lukas Pirl
2015-12-07 8:25 ` Duncan
2015-12-07 10:02 ` Alistair Grant
2015-12-07 13:48 ` Duncan
2015-12-07 19:55 ` Alistair Grant
2015-12-08 15:25 ` Duncan [this message]
2015-12-08 22:38 ` Alistair Grant
2015-12-09 10:19 ` Duncan
2015-12-12 22:12 ` Alistair Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$73edd$edd83c4d$2a373055$4b6032dd@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox