User reports upgrading to kernel 6.10.9 and getting a read-time tree checker warning for the first time (upstream commit f333a3c7e8). Attached dmesg is kernel 6.11.0 showing the same issue. Excerpts: kernel: [ +0,000002] BTRFS critical (device dm-0): corrupt leaf: block=449139843072 slot=15 extent bytenr=34796806144 len=114688 invalid data ref objectid value 5 [ +0,000007] BTRFS error (device dm-0): read time tree block corruption detected on logical 449139843072 mirror 1 [ +0,000005] BTRFS error (device dm-0): read time tree block corruption detected on logical 449139843072 mirror 2 both copies are bad btrfs dump-tree block: item 15 key (34796806144 EXTENT_ITEM 114688) itemoff 3147 itemsize 53 refs 1 gen 472423 flags DATA (178 0xdfb591fce820576) extent data backref root FS_TREE objectid 18446744073709551604 offset 0 count 1 item 16 key (34796920832 EXTENT_ITEM 24576) itemoff 3094 itemsize 53 shows invalid objectid, 0xFFFFFFFFFFFFFFF4 which seems implausible for single bitflip root@localhost-live:~# btrfs check --readonly /dev/mapper/snd Opening filesystem to check... Checking filesystem on /dev/mapper/snd UUID: d7cdb6c9-8cf5-4ef5-b300-3d9ce5b7edf8 [1/7] checking root items [2/7] checking extents [3/7] checking free space cache [4/7] checking fs roots root 307 inode 10776 errors 200, dir isize wrong root 307 inode 17193986 errors 1, no inode item unresolved ref dir 10776 index 2354981 namelen 11 name Preferences filetype 1 errors 5, no dir item, no inode ref ERROR: errors found in fs roots found 312800141312 bytes used, error(s) found total csum bytes: 299089000 total tree bytes: 4268523520 total fs tree bytes: 3501686784 total extent tree bytes: 357617664 btree space waste bytes: 1017279014 file data blocks allocated: 643100499968 referenced 347451535360 root@localhost-live:~# root@localhost-live:~# btrfs check --readonly --mode lowmem /dev/mapper/snd Opening filesystem to check... Checking filesystem on /dev/mapper/snd UUID: d7cdb6c9-8cf5-4ef5-b300-3d9ce5b7edf8 [1/7] checking root items [2/7] checking extents [3/7] checking free space cache [4/7] checking fs roots ERROR: root 5 EXTENT_DATA[61285255 4096] gap exists, expected: EXTENT_DATA[61285255 128] ERROR: root 5 EXTENT_DATA[61285256 4096] gap exists, expected: EXTENT_DATA[61285256 128] ERROR: root 5 EXTENT_DATA[91640367 4096] gap exists, expected: EXTENT_DATA[91640367 128] ERROR: root 5 EXTENT_DATA[91640368 4096] gap exists, expected: EXTENT_DATA[91640368 128] ERROR: root 5 INODE[18446744073709551604] nlink(1) not equal to inode_refs(0) ERROR: invalid imode mode bits: 00 ERROR: invalid inode generation 18446744073709551604 or transid 1 for ino 18446744073709551605, expect [0, 17997523) ERROR: root 5 INODE[18446744073709551605] nlink(120940288) not equal to inode_refs(0) ERROR: root 5 INODE[18446744073709551605] nbytes 5120 not equal to extent_size 0 ERROR: root 307 INODE_ITEM[17193986] index 2354981 name Preferences filetype 1 missing ERROR: root 307 DIR INODE [10776] size 8052 not equal to 8063 ERROR: errors found in fs roots found 312800141312 bytes used, error(s) found total csum bytes: 299089000 total tree bytes: 4268523520 total fs tree bytes: 3501686784 total extent tree bytes: 357617664 btree space waste bytes: 1017279014 file data blocks allocated: 643100499968 referenced 347451535360 Reproducible: Always
Created attachment 2049587 [details] kernel.log
Created attachment 2049588 [details] btrfs inspect dump-t -b 449139843072
Additional questions are: Why does original mode not catch this? Read time tree checker flips the fs RO, so it's not a trivial problem or difficult to detect. And lowmem mode detects it. Are we supposed to ask users to always run both orig and lowmem? Or is lowmem always preferred?
This is caused by the old inode_cache. The original mode has extra hacks to not report errors on them, meanwhile the newer lowmem mode does not treat inode cache with any hacks. It can be fixed by "btrfs rescue clear-ino-cache <device>", however there is a bug fix in v6.11 progs on this, or one may hit some crash during inode clearing and may need run it multiple times to fully clear the cache. Furthermore, v6.11 progs can detect the problem even using original mode check.
Thanks Qu - sorry I missed this myself. I'll work with the user to get it fixed up. Thanks!