> On 2021/4/19 下午10:56, Gervais, Francois wrote: >>> My bad, wrong number. >>> >>> The correct number command is: >>> # btrfs ins dump-tree -b 790151168 /dev/loop0p3 >> >> >> root@debug:~# btrfs ins dump-tree -b 790151168 /dev/loop0p3 >> btrfs-progs v5.7 > [...] >> item 4 key (5007 INODE_ITEM 0) itemoff 15760 itemsize 160 >> generation 294 transid 219603 size 0 nbytes >>18446462598731726987 > > The nbytes looks very strange. > > It's 0x0xfffeffffffef008b, which definitely looks aweful for an empty inode. > >> block group 0 mode 100600 links 1 uid 1000 gid 1000 rdev 0 >> sequence 476091 flags 0x0(none) >> atime 1610373772.750632843 (2021-01-11 14:02:52) >> ctime 1617477826.205928110 (2021-04-03 19:23:46) >> mtime 1617477826.205928110 (2021-04-03 19:23:46) >> otime 0.0 (1970-01-01 00:00:00) >> item 5 key (5007 INODE_REF 4727) itemoff 15732 itemsize 28 >> index 0 namelen 0 name: >> index 0 namelen 0 name: >> index 0 namelen 294 name: > > Definitely corrupted. I'm afraid tree-checker is correct. > > The log tree is corrupted. > And the check to detect such corrupted inode ref is only introduced in > v5.5 kernel, no wonder v5.4 kernel didn't catch it at runtime.
Would detecting it at runtime with a newer kernel have helped in any way with the corruption? > > I don't have any idea why this could happen, as it doesn't look like an > obvious memory flip. The test engineer says that the last thing he did was remove power from the device. Could power loss be the cause of this issue? > > Maybe Filipe could have some clue on this? > > Thanks, > Qu > >> item 6 key (5041 INODE_ITEM 0) itemoff 15572 itemsize 160 >> generation 295 transid 219603 size 4096 nbytes 4096 >> block group 0 mode 100600 links 1 uid 1000 gid 1000 rdev 0 >> sequence 321954 flags 0x0(none) >> atime 1610373832.763235044 (2021-01-11 14:03:52) >> ctime 1617477815.541863825 (2021-04-03 19:23:35) >> mtime 1617477815.541863825 (2021-04-03 19:23:35) >> otime 0.0 (1970-01-01 00:00:00) >> item 7 key (5041 INODE_REF 4727) itemoff 15544 itemsize 28 >> index 12 namelen 18 name: health_metrics.txt >> item 8 key (5041 EXTENT_DATA 0) itemoff 15491 itemsize 53 >> generation 219603 type 1 (regular) >> extent data disk byte 12746752 nr 4096 >> extent data offset 0 nr 4096 ram 4096 >> extent compression 0 (none) >> item 9 key (EXTENT_CSUM EXTENT_CSUM 12746752) itemoff 15487 itemsize 4 >> range start 12746752 end 12750848 length 4096 >>
