On 11/21/2015 03:24 AM, Christoph Anton Mitterer wrote:
On Fri, 2015-11-20 at 17:23 +0100, Laurent Bonnaud wrote:
So here is the output of "btrfs-debug-tree -t 2 <dev>" in case it may
Gosh... 15M via mail?! o.O
Anyway an update from my side...
I've copied all data from the fs in question to a new btrfs,... done
under Linux 4.2.6 and btrfs-progs v4.3.
No data was lost or anyhow corrupted (also shown by extensive tests
using my XATTR hashsums and other backups I've had).
On the new fs, btrfs doesn't report that error anymore.
No snapshots/etc made so far on the new fs.
Qu, have you had a look at btrfs check already?
Nothing interesting found...
And if the codes go crazy, it should also infect your new filesystem,
but it doesn't...
And you've explained that the fs was okay and only the check was
wrong... but since the false positive errors don't appear on my copied
fs, does that really mean that the skinny metadata changed so much, or
was anything changed in the kernel that the same didn't appear on the
new fs anymore (or was it perhaps because I was using snapshots?)
Hard to say, but we'd better keep an eye on this issue.
At least, if it happens again, we should know if it's related to
something like newer kernel or snapshots.
Thanks,
Qu
Cheers,
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
