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.
smime.p7s
Description: S/MIME cryptographic signature
