Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Latest fsck added a lot of more restrict check.

Like this one, if any extent type doesn't match with its chunk, like 
metadata extent in a data chunk, btrfsck will report like that.

The filesystem seems to be a converted one from ext*.
If so, there is no real 100% stable method to recovery it, as 
btrfs-convert has broken for some time, and will cause above problem.

But some user, like Roman Mamedov in the maillist, said a balance 
operation can solve it.
It's worthy trying but it may also cause unknown bugs.

Thanks,
Qu

Christoph Anton Mitterer wrote on 2015/11/12 22:51 +0100:
> Hey.
>
> I get these errors on fsck'ing a btrfs:
> bad extent [5993525264384, 5993525280768), type mismatch with chunk
> bad extent [5993525280768, 5993525297152), type mismatch with chunk
> bad extent [5993525297152, 5993525313536), type mismatch with chunk
> bad extent [5993529442304, 5993529458688), type mismatch with chunk
> bad extent [5993529458688, 5993529475072), type mismatch with chunk
> bad extent [5993530015744, 5993530032128), type mismatch with chunk
> bad extent [5993530359808, 5993530376192), type mismatch with chunk
> bad extent [5993530376192, 5993530392576), type mismatch with chunk
> bad extent [5993530392576, 5993530408960), type mismatch with chunk
> bad extent [5993530408960, 5993530425344), type mismatch with chunk
> bad extent [5993531260928, 5993531277312), type mismatch with chunk
> bad extent [5993531310080, 5993531326464), type mismatch with chunk
>
> What do they mean? And how to correct it without data loss (cause this
> would be critical/precious data)?
>
> Oddly, I've fsck'ed the very same fs last time I've unmounted it (with
> no errors)... and now this.
> The only difference would be newer kernel and btrfsprogs.
>
>
> Thanks,
> Chris.
>