Re: Btrfs Check - "type mismatch with chunk"

[Christoph Anton Mitterer <calestyo@scientia.net>]

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