Christoph Anton Mitterer wrote on 2015/11/13 04:03 +0100:
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...
No, "-t 2" means only dump extent tree, no privacy issues at all.
Since only numeric inode/snapshot number and offset inside file.
Or I'll give you a warning on privacy.
No file name at all, just try it yourself.
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.
It may happened in older kernels, just recent btrfsck can detect the
problem.
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?
Not possible yet.
Since there is not relocation facility in btrfs-progs to do the fix.
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
New enough, that's the only good news yet...
Thanks,
Qu
--
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
