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

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

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

On Fri, 2015-11-13 at 10:52 +0800, Qu Wenruo wrote:
> You can provide the output of "btrfs-debug-tree -t 2 <dev>" to help
> further debug.
> It would be quite big, so it's better to zip it.
That would contain all the filenames, right? Hmm that could be
problematic because of privacy issues...


> Although it may not help a lot, but at least I can tell you which
> file 
> extents are affected. (By the hard way, I can only tell you which
> inode 
> in which subvolume is affected, all in numeric form)
> 
> And I could get enough info to determine what's the wrong type.
> (data extent in metadata chunk or vice verse, or even system chunk is
> involved)
sigh... I mean... how can that happen, if nothing of the more recent
things is used... I'd have guess others would have noted such a bug
before.


> > 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.
> 
> When extent and chunk type get wrong, only god knows what will
> happen...
> So no useful help here.
If btrfs check already notices the mismatch, shouldn't it then be
possible to set the correct type?


> If the type mismatch errors are the only error output from fsck, then
> scrub should not help or report anything useful.
I see...


> And at last, what's the kernel and btrfs-progs version?
kernel 4.2.6
btrfsprogs 4.3

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