On 2019/9/30 下午2:58, Andrey Ivanov wrote: > On 30.09.2019 9:27, Qu Wenruo wrote: >>> This is the kernel message for /dev/sda4. It is also have some problems, >>> but it is successfully mounted. I can't mount /dev/sdc1. >>> >>> Kernel message for /dev/sdc1: >>> [ 6.503265] BTRFS info (device sdc1): disk space caching is enabled >>> [ 6.503266] BTRFS info (device sdc1): has skinny extents >>> [ 8.890135] BTRFS critical (device sdc1): corrupt leaf: root=2 >>> block=855738744832 slot=20, unexpected item end, have 15287 expect 15223 >>> [ 8.899635] BTRFS critical (device sdc1): corrupt leaf: root=2 >>> block=855738744832 slot=20, unexpected item end, have 15287 expect 15223 >> >> This is from extent tree. >> >> Please provide the following dump: >> >> # btrfs ins dump-tree -b 855738744832 /dev/sdc1 > > attached btrfs-ins-dump-tree-855738744832-sdc1.output
OK, tree-checker is again detecting the problem correctly.
item 19 key (613039370240 EXTENT_ITEM 1048576) itemoff 15223 itemsize 53
refs 1 gen 52116 flags DATA
extent data backref root FS_TREE objectid 5841996 offset
607125504 count 1
item 20 key (613040418816 EXTENT_ITEM 1032192) itemoff 15170 itemsize
117
refs 1 gen 52162 flags DATA
extent data backref root FS_TREE objectid 5842000 offset
927858688 count 1
Item 20 should be a regular single reference, but its size is 117.
But please check this:
117 = 0x75
53 = 0x35
The difference is 0x40, which is a single bit.
And if itemsize for slot 20 is regular 53, then it matches its neighbors
without any problem.
So at least to me, this looks like a bitflip.
Although I'm not sure if it's btrfs itself causing the problem or it's
the hardware or even 3rd party kernel modules to blame.
For this one, I could help you by just reverting that bit, and then you
may be able to continue mounting the fs or at least run btrfs check on it.
Please prepare an environment to compile btrfs-progs (at least
btrfs-corrupt-block) if you want to try.
>
>
>>>> [[EXTRA INFO]]
>>>> Please provide the following dump of that tree block by:
>>>> # btrfs ins dump-tree -b 134079905792 /dev/sda4
>>>
>>> attached btrfs-ins-dump-tree-134079905792.output
>>
>> Confirmed.
>>
>> It looks like the data_len got some bitflips.
>>
>> In that offending leaf, there is only two data_len and all are one bit
>> flipped.
>> Considering that directory is not that old, it looks like some memory
>> bit flip.
>>
>> It's recommended to do a memtest to ensure it's not memory causing the
>> problem.
>
> I did a memtest earlier. All had passed without errors. I can do a
> memtest again,
> but it seems to me that if the memory was faulty, the system would not
> be stable
> and often hung, but the system works fine.
Indeed, especially considering that there are already two bitflips in
one leaf, which should be pretty rare.
Any out-of-tree kernel modules? Or would you like to try v5.2.15 kernel,
which has a self detection for such problem.
Thanks,
Qu
>
>
>> I recommend to do a "btrfs check" on all fses.
>
> Can't do check on /dev/sdc1:
>
> # btrfs check /dev/sdc1
> Opening filesystem to check...
> incorrect offsets 15223 15287
> ERROR: cannot open file system
signature.asc
Description: OpenPGP digital signature
