On 2021/4/20 下午10:19, Gervais, Francois wrote:
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?

Yes, newer kernel will reject the write, so such damaged metadata won't reach disk.

But that's just more graceful than corrupted fs.
It will still cause error like transaction aborted.



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?

It shouldn't.
The log tree can only be exposed by power loss, but it's not designed to have such corrupted data on-disk.

This normally means some code is wrong when generating log tree.

Thanks,
Qu



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
>

Reply via email to