From: covici@ccs.covici.com
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Btrfs Check - "type mismatch with chunk"
Date: Fri, 25 Dec 2015 00:28:09 -0500 [thread overview]
Message-ID: <9871.1451021289@ccs.covici.com> (raw)
In-Reply-To: <pan$ed44$b7377cf0$bc775a24$c5211738@cox.net>
Duncan <1i5t5.duncan@cox.net> wrote:
> Zach Fuller posted on Thu, 24 Dec 2015 13:15:22 -0600 as excerpted:
>
> > I am currently running btrfs on a 2TB GPT drive. The drive is working
> > fine, still mounts correctly, and I have experienced no data corruption.
> > Whenever I run "btrfs check" on the drive, it returns 100,000+ messages
> > stating "bad extent [###, ###), type mismatch with chunk". Whenever I
> > try to run "btrfs check --repair" it says that it has fixed the errors,
> > but whenever I run "btrfs check" again, the errors return. Should I be
> > worried about data/filesystem corruption,
> > or are these errors meaningless?
>
> > I have my data backed up on 2 different drives, so I can afford to lose
> > the entire btrfs drive temporarily.
> >
> > Here is some info about my system:
> >
> > $ uname -[r]
> > 4.2.5-1-ARCH
> >
> >
> > $ btrfs --version
> > btrfs-progs v4.3.1
>
> While Chris's reply mentioning a patch is correct, that's not the whole
> story and I suspect you have a problem, as the patch is in the userspace
> 4.3.1 you're running.
>
> How long have you had the filesystem? Was it likely created with the
> mkfs.btrfs from btrfs-progs v4.1.1 (July, 2015) as I suspect? If so, you
> have a problem, as that mkfs.btrfs was buggy and created invalid
> filesystems.
>
> As you have two separate backups and you're not experiencing corruption
> or the like so far, you should be fine, but if the filesystem was created
> with that buggy mkfs.btrfs, you need to wipe and recreate it as soon as
> possible, because it's unstable in its current state and could fail, with
> massive corruption, at any point. Unfortunately, the bug created
> filesystems so broken that (last I knew anyway, and your experience
> agrees) there's no way btrfs check --repair can fix them. The only way
> to fix it is to blow away the filesystem and recreate it with a
> mkfs.btrfs that doesn't have the bug that 4.1.1 did. Your 4.3.1 should
> be fine.
>
> (The patch Chris mentioned was to btrfs check, as the first set of
> patches to it to allow it to detect the problem triggered all sorts of
> false-positives and pretty much everybody was flagged as having the
> problem. I believe that was patched in the 4.2 series, however, and
> you're running 4.3.1, so you should have that patch and the reports
> shouldn't be false positives. Tho if you didn't create the filesystem
> with the buggy mkfs.btrfs from v4.1.1, there's likely some other problem
> to root out, but I'm guessing you did, and thus have the bad filesystem
> the patched btrfs check is designed to report, and that report is indeed
> valid.)
Hmmm, I just used the 4.1 mkfs.btrfs to create some of the file systems
I have, because that was on the cd I booted with because I had to do
this offline. So, can I fix things, ro do I have to find a cd with the
4.3.1 programs, or can I put the mkfs.btrfs binary on a USB drive, copy
the files off, recreate the file systems and do a copy back? grrrr!
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
covici@ccs.covici.com
next prev parent reply other threads:[~2015-12-25 5:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-24 19:15 Btrfs Check - "type mismatch with chunk" Zach Fuller
2015-12-24 21:27 ` Christoph Anton Mitterer
2015-12-24 23:41 ` Duncan
2015-12-25 5:28 ` covici [this message]
2015-12-25 8:06 ` Duncan
2016-01-02 5:12 ` Christoph Anton Mitterer
2016-01-05 15:34 ` Duncan
2016-01-05 18:54 ` Christoph Anton Mitterer
2016-01-05 19:01 ` Martin Steigerwald
2015-12-27 4:01 ` Christoph Anton Mitterer
2015-12-29 0:08 ` Zach Fuller
2015-12-29 4:16 ` Duncan
2015-12-29 4:42 ` Christoph Anton Mitterer
2016-01-02 10:48 ` Martin Steigerwald
2016-01-02 19:52 ` Henk Slager
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=9871.1451021289@ccs.covici.com \
--to=covici@ccs.covici.com \
--cc=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;
as well as URLs for NNTP newsgroup(s).