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? > 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. (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... > 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? > 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. thanks a lot, Chris.
smime.p7s
Description: S/MIME cryptographic signature
