linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] btrfs: rescue: allow ibadroots to skip bad extent tree when reading block group items
@ 2021-07-15  1:24 Qu Wenruo
  2021-07-15  2:17 ` Anand Jain
  0 siblings, 1 reply; 3+ messages in thread
From: Qu Wenruo @ 2021-07-15  1:24 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Qu Wenruo, Zhenyu Wu

When extent tree gets corrupted, normally it's not extent tree root, but
one toasted tree leaf/node.

In that case, rescue=ibadroots mount option won't help as it can only
handle the extent tree root corruption.

This patch will enhance the behavior by:

- Allow fill_dummy_bgs() to ignore -EEXIST error

  This means we may have some block group items read from disk, but
  then hit some error halfway.

- Fallback to fill_dummy_bgs() if any error gets hit in
  btrfs_read_block_groups()

  Of course, this still needs rescue=ibadroots mount option.

With that, rescue=ibadroots can handle extent tree corruption more
gracefully and allow a better recover chance.

Reported-by: Zhenyu Wu <wuzy001@gmail.com>
Link: https://www.spinics.net/lists/linux-btrfs/msg114424.html
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/block-group.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index 5bd76a45037e..33086b882fe8 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -2105,11 +2105,16 @@ static int fill_dummy_bgs(struct btrfs_fs_info *fs_info)
 		bg->used = em->len;
 		bg->flags = map->type;
 		ret = btrfs_add_block_group_cache(fs_info, bg);
-		if (ret) {
+		/*
+		 * We may have some block groups filled already, thus ignore
+		 * the -EEXIST error.
+		 */
+		if (ret && ret != -EEXIST) {
 			btrfs_remove_free_space_cache(bg);
 			btrfs_put_block_group(bg);
 			break;
 		}
+		ret = 0;
 		btrfs_update_space_info(fs_info, bg->flags, em->len, em->len,
 					0, 0, &space_info);
 		bg->space_info = space_info;
@@ -2139,8 +2144,10 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
 	key.offset = 0;
 	key.type = BTRFS_BLOCK_GROUP_ITEM_KEY;
 	path = btrfs_alloc_path();
-	if (!path)
-		return -ENOMEM;
+	if (!path) {
+		ret = -ENOMEM;
+		goto error;
+	}
 
 	cache_gen = btrfs_super_cache_generation(info->super_copy);
 	if (btrfs_test_opt(info, SPACE_CACHE) &&
@@ -2212,6 +2219,13 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
 	ret = check_chunk_block_group_mappings(info);
 error:
 	btrfs_free_path(path);
+	/*
+	 * Either we have no extent_root (already implies IGNOREBADROOTS), or
+	 * we hit error and have IGNOREBADROOTS, then we can try to use dummy
+	 * bgs.
+	 */
+	if (!info->extent_root || (ret && btrfs_test_opt(info, IGNOREBADROOTS)))
+		ret = fill_dummy_bgs(info);
 	return ret;
 }
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs: rescue: allow ibadroots to skip bad extent tree when reading block group items
  2021-07-15  1:24 [PATCH] btrfs: rescue: allow ibadroots to skip bad extent tree when reading block group items Qu Wenruo
@ 2021-07-15  2:17 ` Anand Jain
  2021-07-15  2:25   ` Qu Wenruo
  0 siblings, 1 reply; 3+ messages in thread
From: Anand Jain @ 2021-07-15  2:17 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: Zhenyu Wu, linux-btrfs

On 15/07/2021 09:24, Qu Wenruo wrote:
> When extent tree gets corrupted, normally it's not extent tree root, but
> one toasted tree leaf/node.
> 
> In that case, rescue=ibadroots mount option won't help as it can only
> handle the extent tree root corruption.
> 
> This patch will enhance the behavior by:
> 
> - Allow fill_dummy_bgs() to ignore -EEXIST error
> 
>    This means we may have some block group items read from disk, but
>    then hit some error halfway.
> 
> - Fallback to fill_dummy_bgs() if any error gets hit in
>    btrfs_read_block_groups()
> 
>    Of course, this still needs rescue=ibadroots mount option.
> 
> With that, rescue=ibadroots can handle extent tree corruption more
> gracefully and allow a better recover chance.
> 
> Reported-by: Zhenyu Wu <wuzy001@gmail.com>
> Link: https://www.spinics.net/lists/linux-btrfs/msg114424.html
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>   fs/btrfs/block-group.c | 20 +++++++++++++++++---
>   1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
> index 5bd76a45037e..33086b882fe8 100644
> --- a/fs/btrfs/block-group.c
> +++ b/fs/btrfs/block-group.c
> @@ -2105,11 +2105,16 @@ static int fill_dummy_bgs(struct btrfs_fs_info *fs_info)
>   		bg->used = em->len;
>   		bg->flags = map->type;
>   		ret = btrfs_add_block_group_cache(fs_info, bg);
> -		if (ret) {
> +		/*
> +		 * We may have some block groups filled already, thus ignore
> +		 * the -EEXIST error.
> +		 */
> +		if (ret && ret != -EEXIST) {
>   			btrfs_remove_free_space_cache(bg);
>   			btrfs_put_block_group(bg);
>   			break;
>   		}
> +		ret = 0;
>   		btrfs_update_space_info(fs_info, bg->flags, em->len, em->len,
>   					0, 0, &space_info);
>   		bg->space_info = space_info;


> @@ -2139,8 +2144,10 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
>   	key.offset = 0;
>   	key.type = BTRFS_BLOCK_GROUP_ITEM_KEY;
>   	path = btrfs_alloc_path();
> -	if (!path)
> -		return -ENOMEM;
> +	if (!path) {
> +		ret = -ENOMEM;
> +		goto error;
> +	}

   Return -ENOMEM; is correct as alloc failure is not part of the 
corruption?

Thanks, Anand

>   	cache_gen = btrfs_super_cache_generation(info->super_copy);
>   	if (btrfs_test_opt(info, SPACE_CACHE) &&
> @@ -2212,6 +2219,13 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
>   	ret = check_chunk_block_group_mappings(info);
>   error:
>   	btrfs_free_path(path);
> +	/*
> +	 * Either we have no extent_root (already implies IGNOREBADROOTS), or
> +	 * we hit error and have IGNOREBADROOTS, then we can try to use dummy
> +	 * bgs.
> +	 */
> +	if (!info->extent_root || (ret && btrfs_test_opt(info, IGNOREBADROOTS)))
> +		ret = fill_dummy_bgs(info);
>   	return ret;
>   }
>   
> 


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs: rescue: allow ibadroots to skip bad extent tree when reading block group items
  2021-07-15  2:17 ` Anand Jain
@ 2021-07-15  2:25   ` Qu Wenruo
  0 siblings, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2021-07-15  2:25 UTC (permalink / raw)
  To: Anand Jain; +Cc: Zhenyu Wu, linux-btrfs



On 2021/7/15 上午10:17, Anand Jain wrote:
> On 15/07/2021 09:24, Qu Wenruo wrote:
>> When extent tree gets corrupted, normally it's not extent tree root, but
>> one toasted tree leaf/node.
>>
>> In that case, rescue=ibadroots mount option won't help as it can only
>> handle the extent tree root corruption.
>>
>> This patch will enhance the behavior by:
>>
>> - Allow fill_dummy_bgs() to ignore -EEXIST error
>>
>>    This means we may have some block group items read from disk, but
>>    then hit some error halfway.
>>
>> - Fallback to fill_dummy_bgs() if any error gets hit in
>>    btrfs_read_block_groups()
>>
>>    Of course, this still needs rescue=ibadroots mount option.
>>
>> With that, rescue=ibadroots can handle extent tree corruption more
>> gracefully and allow a better recover chance.
>>
>> Reported-by: Zhenyu Wu <wuzy001@gmail.com>
>> Link: https://www.spinics.net/lists/linux-btrfs/msg114424.html
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   fs/btrfs/block-group.c | 20 +++++++++++++++++---
>>   1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
>> index 5bd76a45037e..33086b882fe8 100644
>> --- a/fs/btrfs/block-group.c
>> +++ b/fs/btrfs/block-group.c
>> @@ -2105,11 +2105,16 @@ static int fill_dummy_bgs(struct btrfs_fs_info 
>> *fs_info)
>>           bg->used = em->len;
>>           bg->flags = map->type;
>>           ret = btrfs_add_block_group_cache(fs_info, bg);
>> -        if (ret) {
>> +        /*
>> +         * We may have some block groups filled already, thus ignore
>> +         * the -EEXIST error.
>> +         */
>> +        if (ret && ret != -EEXIST) {
>>               btrfs_remove_free_space_cache(bg);
>>               btrfs_put_block_group(bg);
>>               break;
>>           }
>> +        ret = 0;
>>           btrfs_update_space_info(fs_info, bg->flags, em->len, em->len,
>>                       0, 0, &space_info);
>>           bg->space_info = space_info;
> 
> 
>> @@ -2139,8 +2144,10 @@ int btrfs_read_block_groups(struct 
>> btrfs_fs_info *info)
>>       key.offset = 0;
>>       key.type = BTRFS_BLOCK_GROUP_ITEM_KEY;
>>       path = btrfs_alloc_path();
>> -    if (!path)
>> -        return -ENOMEM;
>> +    if (!path) {
>> +        ret = -ENOMEM;
>> +        goto error;
>> +    }
> 
>    Return -ENOMEM; is correct as alloc failure is not part of the 
> corruption?

Oh, right. In that case we shouldn't try to fill dummy eb, especially it 
will also fail with -ENOMEM anyway.

Thanks,
Qu
> 
> Thanks, Anand
> 
>>       cache_gen = btrfs_super_cache_generation(info->super_copy);
>>       if (btrfs_test_opt(info, SPACE_CACHE) &&
>> @@ -2212,6 +2219,13 @@ int btrfs_read_block_groups(struct 
>> btrfs_fs_info *info)
>>       ret = check_chunk_block_group_mappings(info);
>>   error:
>>       btrfs_free_path(path);
>> +    /*
>> +     * Either we have no extent_root (already implies 
>> IGNOREBADROOTS), or
>> +     * we hit error and have IGNOREBADROOTS, then we can try to use 
>> dummy
>> +     * bgs.
>> +     */
>> +    if (!info->extent_root || (ret && btrfs_test_opt(info, 
>> IGNOREBADROOTS)))
>> +        ret = fill_dummy_bgs(info);
>>       return ret;
>>   }
>>
> 


^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-07-15  2:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-15  1:24 [PATCH] btrfs: rescue: allow ibadroots to skip bad extent tree when reading block group items Qu Wenruo
2021-07-15  2:17 ` Anand Jain
2021-07-15  2:25   ` Qu Wenruo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).