Btrfs Check - "type mismatch with chunk"

Btrfs Check - "type mismatch with chunk"

[Zach Fuller]

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?

Here are the links to the output of "btrfs check"
(https://app.box.com/s/z2c4ikp6lsn7siezafkth3amo27acs4o) and "btrfs
check --repair"
(https://app.box.com/s/tgg3c4dpfas1wulk30zpudw4mt4bvwoa)
Also, whenever I run btrfs scrub on the drive, it says there are no errors.

I see that there have been other posts on the mailing list with this
same error, such as this one
(https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg48325.html).

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 -a
Linux comp 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015
x86_64 GNU/Linux


$ btrfs --version
btrfs-progs v4.3.1


$ sudo btrfs fi show
Another drive...

Label: 'backup'  uuid: 1a160f37-7206-43f9-9285-6217ee97a665
Total devices 1 FS bytes used 1.53TiB
devid    1 size 1.82TiB used 1.54TiB path /dev/sdc1


$ sudo btrfs fi df /backup
Data, single: total=1.53TiB, used=1.53TiB
System, DUP: total=32.00MiB, used=224.00KiB
Metadata, DUP: total=3.50GiB, used=2.36GiB
GlobalReserve, single: total=512.00MiB, used=0.00B


Drive Mounting Options from /etc/fstab:
LABEL=backup    /backup  btrfs  noatime,compress=lzo,autodefrag  0 0

Re: Btrfs Check - "type mismatch with chunk"

[Christoph Anton Mitterer]

Hey.

There was a patch for that issue.
Simply try that and when it goes away with it, there's probably no further reason to worry.

Cheers,
Chris.

Re: Btrfs Check - "type mismatch with chunk"

[Duncan]

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.)

-- 
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

Re: Btrfs Check - "type mismatch with chunk"

[covici]

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

Re: Btrfs Check - "type mismatch with chunk"

[Duncan]

covici posted on Fri, 25 Dec 2015 00:28:09 -0500 as excerpted:

> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> 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.

[Different "you", Zach F, not covici.]

> 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!

I wasn't personally sure if 4.1 itself was affected or not, but the wiki 
says don't use 4.1.1 as it's broken with this bug, with the quick-fix in 
4.1.2, so I /think/ 4.1 itself is fine.  A scan with a current btrfs 
check should tell you for sure.  But if you meant 4.1.1 and only typed 
4.1, then yes, better redo.


Meanwhile, minor correction, not on the primary mkfs.btrfs bug, but of 
discussion of the detection in btrfs check.  I got the btrfs check 
patches mixed up in my head, and AFAIK, the check for this one was always 
correct, but it still can't be fixed.

The one I got it mixed up with was one triggered by btrfs-convert not 
mkfs.btrfs, detect stripes crossing stripe boundary.  _That_ was the one 
where the initial check patch (or more accurately IIRC, the merge process 
for the patch) had an off-by-one error, triggering all sorts of false-
positives.  The affected btrfs check, according to the wiki changelog, 
was 4.2 (Sept 2015), with the fix in 4.2.1 (also Sept 2015).

But my mixup may also apply to the OP/Zach's case as there's a third 
element I mixed up as well, so the rest of this post is primarily aimed 
at him, tho of course it's available for others, including lurkers and 
googlers who come upon it later, as well. =:^)

Just as the one bug was only triggered by one version of mkfs.btrfs and 
the filesystem should be fine otherwise, the one here is triggered by 
btrfs-convert, and shouldn't appear otherwise.  Unfortunately, the btrfs-
convert bug isn't as nailed down, but btrfs-convert has a warning up on 
the wiki anyway, as currently being buggy and not reliable.

While they're working on a rewrite that should fix the btrfs-convert 
issues, even with it fixed I'd neither use it myself, nor recommend its 
use to others.  Here's why:

1) Sysadmin's rule of backups:  For any level of backup, you either have 
it because you consider the data valuable enough to be worth the trouble, 
modified by the risk factor that you might need to actually use that 
backup, or the fact that you don't have it means that by your actions, 
you are declaring that data _not_ to be worth the hassle factor of that 
backup, modified by the chance that you might need to use it.  Despite 
any after-the-loss protests to the contrary, your before-the-loss actions 
declared the time, hassle and resources saved by not making the backup to 
be more valuable than the data that would have been saved had you made 
it, so by definition, backup or not, you saved what was most important to 
you, either the data if you had the backup, or your time and resources if 
you didn't.

With btrfs itself "stabilizing, but not yet fully stable or mature", that 
risk factor is higher than it would be for a fully stable filesystem, so 
the relative value of the data that's valuable enough to backup will be 
lower.

Meanwhile, the hassle factor of doing the conversion, deleting the saved 
subvolume with the ext* rollback, then doing the recommended defrag and 
balance, is non-zero as well, so it already indicates you place SOME 
value on the data, or it'd be simpler just to blow it away with a 
mkfs.btrfs and start over.  Arguably, then, it's worth a backup if it's 
worth converting.

And starting with a fresh mkfs.btrfs on a different device (or set of 
devices, since unlike with btrfs-convert, with mkfs.btrfs you can start 
with a multi-device filesystem if you like), then copying over your data 
from the existing ext*, automatically gives you that existing ext* copy 
as a backup, without any further work! =:^)

Meanwhile...

2) Any filesystem conversion, by definition, will have to make 
compromises, because if the filesystems were exactly the same format, 
there'd be no need for conversion in the first place, which means that by 
definition, the converted filesystem isn't going to be as good a layout 
as a freshly created filesystem, with the data then copied into it so it 
can use its own native layout.  That's in addition to any limitations on 
format that the convert method forces on to you, like the loss of the 
multi-device choice that you can have from the beginning if you use 
mkfs.btrfs.


Between the two of these, it makes far *far* more sense to keep your 
existing ext* as a backup, create a new btrfs on different device(s) 
using mkfs.btrfs and your choice of options, and then copy the data from 
your ext* backup onto the new btrfs, than it does to try to use convert, 
even when convert is working and there's no chance of additional problems 
using it.  It should actually be faster as well, since while you'll have 
to copy the data over from the ext* backup, you won't have to go thru the 
recommended defrag and balance steps that try to mitigate some of the 
compromises made by the initial convert.


-- 
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

Re: Btrfs Check - "type mismatch with chunk"

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Thu, 2015-12-24 at 23:41 +0000, Duncan wrote:
> as the patch is in the userspace  4.3.1 you're running.
I don't think this is the case.

The commit was b08a740d7b797d870cbc3691b1291290d0815998 and AFAICT,
it's not included in any release yet.

4.3.1 was from Nov 16th, the above commit was from the 26th.


As I've said before, please try with the patch applied (it's in the
devel branch only).


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: Btrfs Check - "type mismatch with chunk"

[Zach Fuller]

Thanks for helping me out. Here's an update on my system.

> 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?
Unfortunately, I do not remember exactly when I created the
filesystem, but I know that it was created either on May 2015 or
before then. I have been using the standard main branch for the
btrfs-progs. WHen I created the btrfs filesystem, I first wiped the
entire drive, created a new GPT on the drive, created a single
partition, and then created the btrfs filesystem on that partition. I
did not convert an ext* filesystem to btrfs. The hard drive model
number is "ST2000DL003-9VT166". I had to do some manual make the drive
use 4K sectors when I set it up because it reported 512 bytes even
though it actually supported 4k. I followed these instructions to do
so (https://wiki.archlinux.org/index.php/Advanced_Format)



I have grabbed the "btrfs-progs-git" package from the AUR, which
should contain the devel branch.
$ sudo btrfs --version
btrfs-progs v4.3.1-31-g0ab3d31

I ran "btrfs check --repair" again on the drive, and no "type mismatch
with chunk" errors were returned.


$ sudo btrfs check --repair /dev/sdc1 2>&1 | tee repair.txt
checking extents
Fixed 0 roots.
checking free space cache
checking fs roots
checking csums
checking root refs
enabling repair mode
Checking filesystem on /dev/sdc1
UUID: 1a160f37-7206-43f9-9285-6217ee97a665
cache and super generation don't match, space cache will be invalidated
found 1681690084900 bytes used err is 0
total csum bytes: 1639800688
total tree bytes: 2534178816
total fs tree bytes: 390807552
total extent tree bytes: 142917632
btree space waste bytes: 438755239
file data blocks allocated


I then mounted the drive, ran "du -s", unmounted the drive again, and
ran "btrfs check" one more time to see if any errors remained:


$ sudo btrfs check  /dev/sdc1 2>&1 | tee check2.txt
checking extents
checking free space cache
Wanted bytes 737280, found 1245184 for off 5683961462784
Wanted bytes 536870912, found 1245184 for off 5683961462784
cache appears valid but isnt 5683961462784
Checking filesystem on /dev/sdc1
UUID: 1a160f37-7206-43f9-9285-6217ee97a665
found 1681690084900 bytes used err is -22
total csum bytes: 1639800688
total tree bytes: 2534178816
total fs tree bytes: 390807552
total extent tree bytes: 142917632
btree space waste bytes: 438755239
file data blocks allocated: 1802146615296
 referenced 1782959542272


I'm not sure what the output of the above check means, but there are
certainly less errors than before. Should I be worried about these
"free space cache" errors?

It seems that the newer version of "btrfs-progs" from the devel branch
fixed the problem. The drive still mounts and functions correctly.
Should I continue to run the devel branch, or should I switch back to
the main branch? I would prefer to have a stable system rather than
being on the bleeding edge.

On Sat, Dec 26, 2015 at 10:01 PM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> On Thu, 2015-12-24 at 23:41 +0000, Duncan wrote:
>> as the patch is in the userspace  4.3.1 you're running.
> I don't think this is the case.
>
> The commit was b08a740d7b797d870cbc3691b1291290d0815998 and AFAICT,
> it's not included in any release yet.
>
> 4.3.1 was from Nov 16th, the above commit was from the 26th.
>
>
> As I've said before, please try with the patch applied (it's in the
> devel branch only).
>
>
> Cheers,
> Chris.

Re: Btrfs Check - "type mismatch with chunk"

[Duncan]

Zach Fuller posted on Mon, 28 Dec 2015 18:08:12 -0600 as excerpted:

> I have grabbed the "btrfs-progs-git" package from the AUR, which should
> contain the devel branch.
> $ sudo btrfs --version btrfs-progs v4.3.1-31-g0ab3d31
> 
> I ran "btrfs check --repair" again on the drive, and no "type mismatch
> with chunk" errors were returned.

So Chris A Mitterer's belief that the fix was in integration but not 
released yet seems to be correct.

[snip some output with free-space-cache errors]

> I'm not sure what the output of the above check means, but there are
> certainly less errors than before. Should I be worried about these "free
> space cache" errors?

No.  Free-space-cache errors get detected and fixed in normal use, so the 
check output for them is primarily informational.

> It seems that the newer version of "btrfs-progs" from the devel branch
> fixed the problem. The drive still mounts and functions correctly.
> Should I continue to run the devel branch, or should I switch back to
> the main branch? I would prefer to have a stable system rather than
> being on the bleeding edge.

That's an interesting question, the answer to which ultimately depends on 
your own definitions of stable as opposed to bleeding edge.  However, 
given that you're running Arch, not some mostly half-decade-old 
enterprise distro with fixes backported, I imagine your definition of 
"stable" can't be /too/ conservative.

The fact is that as widely accepted on the list, btrfs itself, while no 
longer "experimental" "eat your babies" unstable, remains "still 
stabilizING, not yet fully stable and mature."  As such, people really 
interested in "stable", as in those people mentioned above that are 
running half decade old enterprise distros with fixes backported, really 
shouldn't be running it at all.  Tho some such distros are choosing to 
support btrfs, which is their business, but then the people running those 
distros and using their btrfs should really be getting support from them, 
not from the list, since on the list we don't generally consider btrfs 
suitably stable for that, and only the distros know what they're 
backporting to their nominally really old kernel and userspace version 
numbers anyway, so the list really /can't/ properly support them.

But like I said, you're running arch, which itself indicates that you're 
not enterprise-level stal^hble conservative.  And you're running btrfs, 
which assuming you did your research before just jumping into, indicates, 
as does the fact that you actually did try the live-git integration 
version when necessary, that you /are/ willing to go live-git when 
necessary (or alternatively wait for a fix to hit mainline, as some users 
do when the btrfs they need fixed isn't critical to daily operations), 
even if you prefer not to do it longer term.

And being an informed btrfs user who knows its current status, you 
presumably also either have tested backups or are willing to declare what 
was on that btrfs lost if worse comes to worse.

With that in mind, I'd suggest that like me here on gentoo, you could run 
current btrfs release userspace and release or rc kernels, and simply be 
prepared to build a live-git version or possibly revert to an older 
version, if you run into a bug where it's necessary.

-- 
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

Re: Btrfs Check - "type mismatch with chunk"

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

On Mon, 2015-12-28 at 18:08 -0600, Zach Fuller wrote:
> I ran "btrfs check --repair" again on the drive, and no "type
> mismatch
> with chunk" errors were returned.
You should always be very conservative in using --repair...
AFAIU, it *may* do more bad than good,... often the best idea is to
either wait till some developer encourages you do try it or as a last
resort...

If you do have backups, than I'd suggest now is the time you start to
diff your precious data, to find out whether anything may have been
corrupted.


> I then mounted the drive, ran "du -s", unmounted the drive again, and
> ran "btrfs check" one more time to see if any errors remained:
> 
> 
> $ sudo btrfs check  /dev/sdc1 2>&1 | tee check2.txt
> checking extents
> checking free space cache
> Wanted bytes 737280, found 1245184 for off 5683961462784
> Wanted bytes 536870912, found 1245184 for off 5683961462784
> cache appears valid but isnt 5683961462784
> Checking filesystem on /dev/sdc1
> UUID: 1a160f37-7206-43f9-9285-6217ee97a665
> found 1681690084900 bytes used err is -22

> I'm not sure what the output of the above check means, but there are
> certainly less errors than before. Should I be worried about these
> "free space cache" errors?
Well it does seems as if something would still not be as it should...
:-/

So my recommendation would be... (unless someone more senior on the
list has a better advise)... backup your current data, compare it with
previous backups,... and start with a fresh filesystem... or at least
that's what I personally would do - but I'm uber careful, and others
would maybe just continue with the fs as is, as long as it doesn't show
severe problems during usage.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: Btrfs Check - "type mismatch with chunk"

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

On Fri, 2015-12-25 at 08:06 +0000, Duncan wrote:
> I wasn't personally sure if 4.1 itself was affected or not, but the
> wiki 
> says don't use 4.1.1 as it's broken with this bug, with the quick-fix 
> in 
> 4.1.2, so I /think/ 4.1 itself is fine.  A scan with a current btrfs 
> check should tell you for sure.  But if you meant 4.1.1 and only
> typed 
> 4.1, then yes, better redo.
What exactly was that bug in 4.1.1 mkfs and how would one notice that
one suffers from it?
I created a number of personal filesystems that I use "productively"
and I'm not 100% sure during which version I've created them... :/

Is there some easy way to find out, like a fs creation time stamp??


> Unfortunately, the
> btrfs-
> convert bug isn't as nailed down, but btrfs-convert has a warning up
> on 
> the wiki anyway, as currently being buggy and not reliable.
I hope I don't step on anyone's toes who puts efforts into this, but in
all doing respect,... I think the whole convert thing is at least in
parts a waste of manpower - or perhaps better said: it would be nice to
have, but given the lack of manpower at btrfs development and the
numerous areas[0] that would need some urgent and probably lots of
care,... having a convert from other fs to btrfs seems like luxury that
isn't really needed.

People don't choose btrfs because they can easy convert, I'd guess.
Either they'll choose it (at some time in the future), because it's the
default in distros then,... or they choose it already nowadays because
it's already pretty great and has awesome features.

The conversion is always a think, which at best works and doesn't make
things worse[1],... in practise though it's rather likely to fail than
to work, because the convert tools would need to keep up with
developments at both side (btrfs and e.g. ext) forever.

If people want to change their fs, they should simply copy the data
from on to the other.
Saves a lot of time for the devs :-)



Cheers,
Chris.


[0] From the really awful things like the UUID collision->corruption
issues,... over the pretty serious things like all the missing RAID
functionality (just look at the recent reports at the list where even
RAID1 seems to be far from production ready, not to talk about 5/6),...
and many other bugs (like all the recent error reports about non
working scrubs, etc.)... to the really strongly desired wishlist-
features

[1] It's kinda like the situation when many photographers think it
makes sense to convert their XYZ RAW format to DNG, which is IMHO
inherently stupid. At best all information from XYZ would be preserved
(which is however unlikely) at worst you loose information.
And since there are good readers (dcraw) for basically all RAW formats
there's really not much need to convert it to DNG.
(Which doesn't mean I wouldn't like DNG, but it only makes sense if the
camera does it natively.)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: Btrfs Check - "type mismatch with chunk"

[Martin Steigerwald]

Am Donnerstag, 24. Dezember 2015, 23:41:06 CET schrieb Duncan:
> 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.)

I have this issue as well on one of the filesystems I just checked in order to 
describe to John how to have a go at fixing his filesystem. A tone of these 
with different numbers:

bad extent [347045888, 347062272), type mismatch with chunk

It doesn´t go away with running btrfs check --repair on it.

Last scrub was from yesterday and returned with 0 errors. I will rerun a scrub 
again after the repair attempt. And if its good I will play it safe and redo 
the filesystem from scratch.

It may have been I used a mkfs.btrfs from 4.1.1 for creating it. Would be good 
if it stored the version of the tool that created the fs into the fs itself to 
be able to know for sure. It is the youngest BTRFS filesystem on my laptop 
SSDs. I created it about April 2014 tough.

Thanks,
-- 
Martin

Re: Btrfs Check - "type mismatch with chunk"

[Henk Slager]

On Sat, Jan 2, 2016 at 11:48 AM, Martin Steigerwald <martin@lichtvoll.de> wrote:
> Am Donnerstag, 24. Dezember 2015, 23:41:06 CET schrieb Duncan:
>> 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.)
>
> I have this issue as well on one of the filesystems I just checked in order to
> describe to John how to have a go at fixing his filesystem. A tone of these
> with different numbers:
>
> bad extent [347045888, 347062272), type mismatch with chunk
>
> It doesn´t go away with running btrfs check --repair on it.
>
> Last scrub was from yesterday and returned with 0 errors. I will rerun a scrub
> again after the repair attempt. And if its good I will play it safe and redo
> the filesystem from scratch.
>
> It may have been I used a mkfs.btrfs from 4.1.1 for creating it. Would be good
> if it stored the version of the tool that created the fs into the fs itself to
> be able to know for sure. It is the youngest BTRFS filesystem on my laptop
> SSDs. I created it about April 2014 tough.
Maybe you mean 2015 ...

The detailed error case w.r.t. 4.1.1 progs:
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg44719.html

I have a btrfs fs created with kernel 3.11 / tools 31.2 back in
November 2013, and it also has tons of those 'type mismatch with
chunk' errors (latest check was with kernel 4.4-rc7 / tools 4.3.1).
They are already there for at least half a year. When the patch that
handles this error correctly is included in a new formal tools
release, I might run a repair. So far, the fs / system is stable and
has several clone/backup filesystems (that do not have this problem,
are also younger).

Re: Btrfs Check - "type mismatch with chunk"

[Duncan]

Christoph Anton Mitterer posted on Sat, 02 Jan 2016 06:12:46 +0100 as
excerpted:

> On Fri, 2015-12-25 at 08:06 +0000, Duncan wrote:
>> I wasn't personally sure if 4.1 itself was affected or not, but the
>> wiki says don't use 4.1.1 as it's broken with this bug, with the
>> quick-fix in 4.1.2, so I /think/ 4.1 itself is fine.  A scan with a
>> current btrfs check should tell you for sure.  But if you meant 4.1.1
>> and only typed 4.1, then yes, better redo.

> What exactly was that bug in 4.1.1 mkfs and how would one notice that
> one suffers from it?
> I created a number of personal filesystems that I use "productively" and
> I'm not 100% sure during which version I've created them... :/
> 
> Is there some easy way to find out, like a fs creation time stamp??

I believe a current btrfs check will flag the errors, but can't fix them, 
as the problem was in the filesystem creation and is simply too deep to 
fix, so the bad filesystems must be wiped and recreated with a mkfs.btrfs 
without the bug, to fix.

There's a current or near-current thread (say from Dec 28 or newer) that 
seems to have the specific errors btrfs check reports, based on others' 
replies.  I'm getting behind on this list so won't go attempting to find 
it ATM, and haven't seen the problem myself, so...

>> Unfortunately, the btrfs-
>> convert bug isn't as nailed down, but btrfs-convert has a warning up on
>> the wiki anyway, as currently being buggy and not reliable.

> I hope I don't step on anyone's toes who puts efforts into this, but in
> all doing respect,... I think the whole convert thing is at least in
> parts a waste of manpower - or perhaps better said: it would be nice to
> have, but given the lack of manpower at btrfs development and the
> numerous areas[0] that would need some urgent and probably lots of
> care,... having a convert from other fs to btrfs seems like luxury that
> isn't really needed.

Were btrfs development a zero-sum game, I'd tend to agree with you.  
However, in a free/libre and open source software environment where
many/most contributions are from volunteers, either directly or because 
someone with resources who can't themselves do the coding has taken an 
interest and is effectively volunteering to exchange some of those 
resources for code, things are a bit different.  Code talks, and the 
people volunteering (directly or indirectly) to do that coding scratch, 
or choose not to scratch by spending their time and/or resources 
elsewhere, their own itches in the priority they choose.  That 
environment -- our environment as a FLOSS project -- is no longer zero-
sum as you can't force volunteers to work on something they're not 
interested in -- they walk away and do something else instead.

And obviously, here we have someone with a particular itch to do btrfs-
convert.  To the extent that their code works, as you said, it's it's 
nice to have, particularly if the alternative isn't that some other part 
of btrfs works better, but that they walk away and do their volunteering 
on some other project instead.

Of course right now the code isn't working so well, thus the big warning 
on the wiki and the various recommendations here not to use it.  But to 
the extent that someone takes an interest and fixes it to work again and 
their code is to project standard, particularly if their work doesn't 
come at the expense of other btrfs code, as it may well not if it's 
something a dev takes as a personal challenge and thus puts more hours 
into it than he would into anything else btrfs related, who are we to say 
no, we aren't going to take that unarguably useful code?


It's the same reason that I as a kde user who finds the gnome "dumb-down" 
approach horribly frustrating, remain extremely glad there's a gnome 
project for those who approve of that sort of approach to work on -- by 
definition, they'd find working on kde, with its plethora of options 
approach, extremely frustrating, and would either walk away, or worse yet 
for those who prefer kde's approach, muck things up with fights that 
either take away options or at minimum cause less actual kde work to get 
done.  People who complain about gnome and kde and xfce and ... all 
taking away effort from each other simply don't understand how freedomware 
works, and that it's not a question of wasting effort that could be 
better put to use elsewhere, but of either not having that effort spent 
at all or worse yet, of starting fights so less gets done and more people 
simply quit in frustration.


So it's not a zero-sum game at all, and if the choice is in having 
someone that's interested in btrfs-convert spend time on it, or having 
them not working on btrfs at all, as is very possibly the case, I, and I 
guess most on the project, would prefer they spend the time on
btrfs-convert, even if it's not the absolutely most critical tool in the 
btrfs-tools package. =:^)

-- 
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

Re: Btrfs Check - "type mismatch with chunk"

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

On Tue, 2016-01-05 at 15:34 +0000, Duncan wrote:
> >What exactly was that bug in 4.1.1 mkfs and how would one notice
> > that
> > one suffers from it?
> > I created a number of personal filesystems that I use
> > "productively" and
> > I'm not 100% sure during which version I've created them... :/
> > 
> > Is there some easy way to find out, like a fs creation time stamp??
> 
> I believe a current btrfs check will flag the errors, but can't fix
> them, 
> as the problem was in the filesystem creation and is simply too deep
> to 
> fix, so the bad filesystems must be wiped and recreated with a
> mkfs.btrfs 
> without the bug, to fix.
If I didn't mix things up, there was a post by someone just few days
ago, which showed the error that would pop up on fsck.


> the 
> people volunteering (directly or indirectly) to do that coding
> scratch, 
> or choose not to scratch by spending their time and/or resources 
> elsewhere, their own itches in the priority they choose.
Sure that,'s all clear.
And obviously I didn't want to distract anyone from working on it. It's
just if those people wouldn't care on which part of btrfs they're
working,... than I'd have considered btrfs-convert rather just a nice-
to have.


> It's the same reason that I as a kde user who finds the gnome "dumb-
> down" 
> approach horribly frustrating, remain extremely glad there's a gnome 
> project for those who approve of that sort of approach to work on -- 
I'd rather have wished that all those guys get hired by Apple or MS ;-)


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: Btrfs Check - "type mismatch with chunk"

[Martin Steigerwald]

Am Dienstag, 5. Januar 2016, 15:34:35 CET schrieb Duncan:
> Christoph Anton Mitterer posted on Sat, 02 Jan 2016 06:12:46 +0100 as
> 
> excerpted:
> > On Fri, 2015-12-25 at 08:06 +0000, Duncan wrote:
> >> I wasn't personally sure if 4.1 itself was affected or not, but the
> >> wiki says don't use 4.1.1 as it's broken with this bug, with the
> >> quick-fix in 4.1.2, so I /think/ 4.1 itself is fine.  A scan with a
> >> current btrfs check should tell you for sure.  But if you meant 4.1.1
> >> and only typed 4.1, then yes, better redo.
> > 
> > What exactly was that bug in 4.1.1 mkfs and how would one notice that
> > one suffers from it?
> > I created a number of personal filesystems that I use "productively" and
> > I'm not 100% sure during which version I've created them... :/
> >
> > 
> >
> > Is there some easy way to find out, like a fs creation time stamp??
> 
> I believe a current btrfs check will flag the errors, but can't fix them, 
> as the problem was in the filesystem creation and is simply too deep to 
> fix, so the bad filesystems must be wiped and recreated with a mkfs.btrfs 
> without the bug, to fix.

btrfs check from btrfs tools 4.3.1 on kernel 4.4-rc6 has not been able to fix 
these errors and I recreated the filesystem that had the errors. I think I 
mentioned it also in this thread.

Thanks,
-- 
Martin