Christoph Anton Mitterer wrote on 2015/11/13 03:26 +0100:
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?
It can be done by the btrfs-debug-tree way.
But it's never a user-friendly one...
Not sure if there is a good tool.
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.
So there is some bug hidden...
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?
I'm not a experienced btrfs user, so no good advice here.
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.
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.
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)
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.
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.
If the type mismatch errors are the only error output from fsck, then
scrub should not help or report anything useful.
And at last, what's the kernel and btrfs-progs version?
Thanks,
Qu
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
