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

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

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

Hey.

On Fri, 2015-11-13 at 10:13 +0800, Qu Wenruo wrote:
> 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.
So these errors... are they anything serious? I.e. like data
loss/corruption? Or is it more a "cosmetic" issue?

And would there be a way for btrfs check to repair that thing?

And is there a way to find out to which file these extents belong?


> The filesystem seems to be a converted one from ext*.
No,it was not... any other reasons that could cause this?

It's actually a very plain btrfs... no RAID, no qgroups,... the only
thing I really did was creating snapshots and incrementally send'ing
them to other btrfs (i.e. the backups).
I'd have expected that btrfs is more or less table in these cases.


> 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.
So what's the safest way? Copying off all data and creating the fs from
scratch?
If so, is there a (safe) way to copy a fully fs with the snapshots?

But as I've said, this wasn't an ext converted fs, so in case I do this
or the balance we probably loose any chances to further debug.

And is there any way to tell more certain, whether the balance would
help or whether I'd just get more possibly even hidden corruptions? I
mean right... well it would be painful to recover from the most recent
backup, but not extremely painful.


Right now I'm doing a full read-only scrub, which will take a while as
it's a nearly full 8TB HDD, so far no errors.


Thanks,
Chris.

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