On 2018/8/28 下午9:29, Larkin Lowrey wrote: > On 8/27/2018 10:12 PM, Larkin Lowrey wrote: >> On 8/27/2018 12:46 AM, Qu Wenruo wrote: >>> >>>> The system uses ECC memory and edac-util has not reported any errors. >>>> However, I will run a memtest anyway. >>> So it should not be the memory problem. >>> >>> BTW, what's the current generation of the fs? >>> >>> # btrfs inspect dump-super <device> | grep generation >>> >>> The corrupted leaf has generation 2862, I'm not sure how recent did the >>> corruption happen. >> >> generation 358392 >> chunk_root_generation 357256 >> cache_generation 358392 >> uuid_tree_generation 358392 >> dev_item.generation 0 >> >> I don't recall the last time I ran a scrub but I doubt it has been >> more than a year. >> >> I am running 'btrfs check --init-csum-tree' now. Hopefully that clears >> everything up. > > No such luck: > > Creating a new CRC tree > Checking filesystem on /dev/Cached/Backups > UUID: acff5096-1128-4b24-a15e-4ba04261edc3 > Reinitialize checksum tree > csum result is 0 for block 2412149436416 > extent-tree.c:2764: alloc_tree_block: BUG_ON `ret` triggered, value -28 It's ENOSPC, meaning btrfs can't find enough space for the new csum tree blocks. I could try to enhance the behavior, from current one to delete tree blocks first and then refill. But this needs some extra time to implement. BTW, from the line number, it's not the latest btrfs-progs. Thanks, Qu > btrfs(+0x1da16)[0x55cc43796a16] > btrfs(btrfs_alloc_free_block+0x207)[0x55cc4379c177] > btrfs(+0x1602f)[0x55cc4378f02f] > btrfs(btrfs_search_slot+0xed2)[0x55cc43790be2] > btrfs(btrfs_csum_file_block+0x48f)[0x55cc437a213f] > btrfs(+0x55cef)[0x55cc437cecef] > btrfs(cmd_check+0xd49)[0x55cc437ddbc9] > btrfs(main+0x81)[0x55cc4378b4d1] > /lib64/libc.so.6(__libc_start_main+0xeb)[0x7f4717e6324b] > btrfs(_start+0x2a)[0x55cc4378b5ea] > Aborted (core dumped) > > --Larkin
Attachment:
signature.asc
Description: OpenPGP digital signature
