Re: Scrub aborts due to corrupt leaf

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2232 bytes --]



On 2018/8/28 下午9:56, Chris Murphy wrote:
> 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.

Pretty strange.

This either means chunk allocator doesn't work or we have something else
wrong.

I'll take a look into this problem.

Thanks,
Qu

> 
>> 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.
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]