From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs send kernel error btrfs_compare_tree
Date: Sun, 9 Mar 2014 13:55:12 +0000 (UTC) [thread overview]
Message-ID: <pan$c437$d4e1a698$ae626ce6$8ef08785@cox.net> (raw)
In-Reply-To: 531B7F04.30908@travislists.com
Travis Cross posted on Sat, 08 Mar 2014 20:35:16 +0000 as excerpted:
> The filesystem here was likely created with Linux 3.2 and hasn't seen
> much use for awhile, until today I mounted it to try to btrfs send off
> those volumes.
>
> xaba noted this could be the result of some 3.2-era kernel bug. He
> recognized the messages I was seeing. If this is the case, and this
> sort of thing is common, it seems we might want to have a way of
> detecting this and trying to salvage the situation (particularly as
> Debian wheezy -- the last Debian stable release -- is on a 3.2 kernel).
Well, until 3.13 (IIRC) btrfs was officially experimental, with a very
strongly worded warning on the kernel option activating it. And even
after that semi-stabilization (the wording still doesn't suggest fully
stable) current wiki and mkfs.btrfs strongly encourage keeping current on
your kernel if you're running btrfs, something kernel 3.2 definitely is
*NOT*.
So I'd consider backing up the data and doing a clean mkfs.btrfs on the
filesystem, starting over with a filesystem created with a post-eat-your-
babies-warning kernel. I did that here recently, taking advantage of
several of the newer btrfs disk-format features, and plan to do it again
at least once more after a few more kernel cycles of code settling, just
to be sure I'm not relying on something written by potentially still
buggy and not yet entirely stable btrfs code.
Tho I expect the devs will try to salvage this specific situation and
have a bug-fix for it. But I know at least personally, I rest better
knowing that none of my btrfs has been touched by that officially still
very experimental code; they've all been redone with a newer kernel
beyond that warning and haven't run anything older, and as I said, I plan
to redo them again at least once more, as btrfs settles down further.
--
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:[~2014-03-09 13:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-08 18:40 btrfs send kernel error btrfs_compare_tree Travis Cross
2014-03-08 20:35 ` Travis Cross
2014-03-09 13:55 ` Duncan [this message]
2014-03-09 4:26 ` Chris Samuel
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$c437$d4e1a698$ae626ce6$8ef08785@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.