在 2015年11月14日 10:29, Christoph Anton Mitterer 写道:
On Sat, 2015-11-14 at 09:22 +0800, Qu Wenruo wrote:
Manually checked they all.
thanks a lot :-)


Strangely, they are all OK... although it's a good news for you.
Oh man... you're soooo mean ;-D


They are all tree blocks and are all in metadata block group.
and I guess that's... expected/intended?

Yes, that's the expected behavior.
But dismatch with btrfsck error report.


It seems to be a btrfsck false alert
that's a relieve (for me)

Well I've already started to copy all files from the device to a new
one... unfortunately I'll loose all older snapshots (at least on the
new fs) but instead I get skinny-metadata, which wasn't the default
back then.

Skinny metadata is quite nice feature, hugely reduce the space of metadata extent item size.

(being able to copy a full fs, with all subvols/snapshots is IMHO
really something that should be worked on)


If type is wrong, all the extents inside the chunk should be reported
as
mismatch type with chunk.
Isn't that the case? At least there are so many reported extents...

If you posted all the output, that's just a little more than nothing.
Just tens of error reported, compared to millions of extents.
And in your case, if a chunk is really bad, it will report about 65K errors.


And according to the dump result, the reported ones are not
continuous
even they have adjacent extents but adjacent ones are not reported.
I'm not so deep into btrfs... is this kinda expected and if not how
could all this happen? Or is it really just a check issue and
filesystem-wise fully as it should be?

I think it's a btrfsck issue, at least from the dump info, your extent tree is OK. And if there is no other error reported from btrfsck, your filesystem should be OK.



Did you have any smaller btrfs with the same false alert?
Uhm... I can check, but I don't think so, especially as all other btrfs
I have are newer and already have skinny-metadata.
The only ones I had without are those two big 8TB HDDs...
Unfortunately they contain sensitive data from work, which I don't
think I can copy, otherwise  could have sent you the device or so...

Although I'll check the code to find what's wrong, but if you have
any
small enough image, debugging will be much much faster.
In any case, I'll keep the fs in question for a while, so that I can do
verifications in case you have patches.

Nice.

Thanks,
Qu

thanks a lot,
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

Reply via email to