On Tue, Aug 28, 2018 at 7:42 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > 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.
Seems bogus, there's >4TiB unallocated. >Label: none uuid: acff5096-1128-4b24-a15e-4ba04261edc3 > Total devices 1 FS bytes used 66.61TiB > devid 1 size 72.77TiB used 68.03TiB path /dev/mapper/Cached-Backups > >Data, single: total=67.80TiB, used=66.52TiB >System, DUP: total=40.00MiB, used=7.41MiB >Metadata, DUP: total=98.50GiB, used=95.21GiB >GlobalReserve, single: total=512.00MiB, used=0.00B Even if all metadata is only csum tree, and ~200GiB needs to be written, there's plenty of free space for it. -- Chris Murphy
