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.

What a shame.
Btrfs won't try to allocate new chunk if we're allocating new tree
blocks for metadata trees (extent, csum, etc).

One quick (and dirty) way to avoid such limitation is to use the
following patch
------
diff --git a/extent-tree.c b/extent-tree.c
index 5d49af5a901e..0a1d21a8d148 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -2652,17 +2652,15 @@ int btrfs_reserve_extent(struct
btrfs_trans_handle *trans,
                profile = BTRFS_BLOCK_GROUP_METADATA | alloc_profile;
        }

-       if (root->ref_cows) {
-               if (!(profile & BTRFS_BLOCK_GROUP_METADATA)) {
-                       ret = do_chunk_alloc(trans, info,
-                                            num_bytes,
-                                            BTRFS_BLOCK_GROUP_METADATA);
-                       BUG_ON(ret);
-               }
+       if (!(profile & BTRFS_BLOCK_GROUP_METADATA)) {
                ret = do_chunk_alloc(trans, info,
-                                    num_bytes + SZ_2M, profile);
+                                    num_bytes,
+                                    BTRFS_BLOCK_GROUP_METADATA);
                BUG_ON(ret);
        }
+       ret = do_chunk_alloc(trans, info,
+                            num_bytes + SZ_2M, profile);
+       BUG_ON(ret);

        WARN_ON(num_bytes < info->sectorsize);
        ret = find_free_extent(trans, root, num_bytes, empty_size,
------

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