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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
