All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.