On 30.09.2019 10:31, Qu Wenruo wrote:
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.
I ran memtest86 and discovered that, indeed, one of the memory modules has a bit flip:
https://drive.google.com/file/d/1pnHfUcoSwH8DEnWfl0S7newMLBVo3eXE/view?usp=sharing
https://drive.google.com/file/d/1iDOlSFfMSZ1ffxrSQTeXDmv0luOHT3yS/view?usp=sharing
As you can see on screenshots, two bits flip:
- 0x00400000
- 0x00010000
> 117 = 0x75
> 53 = 0x35
>
> The difference is 0x40, which is a single bit.
I think it's the 0x00400000 bit.
