Re: Scrub aborts due to corrupt leaf

[Chris Murphy <lists@colorremedies.com>]

On Tue, Aug 28, 2018 at 7:42 AM, Qu Wenruo <quwenruo.btrfs@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