All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Anand Jain <anand.jain@oracle.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 01/12] btrfs: scrub: use dedicated super block verification function to scrub one super block
Date: Tue, 21 Mar 2023 15:25:18 +0800	[thread overview]
Message-ID: <16b37d65-8b90-f5b1-0f30-41cf392689a5@gmx.com> (raw)
In-Reply-To: <a70957b6-e9df-c50f-0b76-8524a56f64a1@oracle.com>



On 2023/3/21 13:22, Anand Jain wrote:
> On 20/03/2023 10:12, Qu Wenruo wrote:
>> There is really no need to go through the super complex scrub_sectors()
>> to just handle super blocks.
>>
>> This patch will introduce a dedicated function (less than 50 lines) to
>> handle super block scrubing.
>>
>> This new function will introduce a behavior change, instead of using the
>> complex but concurrent scrub_bio system, here we just go
>> submit-and-wait.
>>
>> There is really not much sense to care the performance of super block
>> scrubbing. It only has 3 super blocks at most, and they are all scattered
>> around the devices already.
>>
> 
> Looks good
> 
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
> 
> Reviewed-by: Anand Jain <anand.jain@oracle.com>
> 
> nits below:
> 
>> ---
>>   fs/btrfs/scrub.c | 54 +++++++++++++++++++++++++++++++++++++++++-------
>>   1 file changed, 46 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
>> index 3cdf73277e7e..e765eb8b8bcf 100644
>> --- a/fs/btrfs/scrub.c
>> +++ b/fs/btrfs/scrub.c
>> @@ -4243,18 +4243,59 @@ int scrub_enumerate_chunks(struct scrub_ctx 
>> *sctx,
>>       return ret;
>>   }
>> +static int scrub_one_super(struct scrub_ctx *sctx, struct 
>> btrfs_device *dev,
>> +               struct page *page, u64 physical, u64 generation)
>> +{
>> +    struct btrfs_fs_info *fs_info = sctx->fs_info; > +    struct 
>> bio_vec bvec;
>> +    struct bio bio;
>> +    struct btrfs_super_block *sb = page_address(page);
>> +    int ret;
>> +
>> +    bio_init(&bio, dev->bdev, &bvec, 1, REQ_OP_READ);
>> +    bio.bi_iter.bi_sector = physical >> SECTOR_SHIFT;
>> +    bio_add_page(&bio, page, BTRFS_SUPER_INFO_SIZE, 0);
>> +    ret = submit_bio_wait(&bio);
>> +    bio_uninit(&bio);
>> +
>> +    if (ret < 0)
>> +        return ret;
>> +    ret = btrfs_check_super_csum(fs_info, sb);
>> +    if (ret != 0) {
>> +        btrfs_err_rl(fs_info,
>> +            "super block at physical %llu devid %llu has bad csum",
>> +            physical, dev->devid);
>> +        return -EIO;
>> +    }
>> +    if (btrfs_super_generation(sb) != generation) {
>> +        btrfs_err_rl(fs_info,
>> +"super block at physical %llu devid %llu has bad generation, has %llu 
>> expect %llu",
>> +                 physical, dev->devid,
>> +                 btrfs_super_generation(sb), generation);
>> +        return -EUCLEAN;
>> +    }
>> +
>> +    ret = btrfs_validate_super(fs_info, sb, -1);
>> +    return ret;
>> +}
>> +
>>   static noinline_for_stack int scrub_supers(struct scrub_ctx *sctx,
>>                          struct btrfs_device *scrub_dev)
>>   {
> 
>   scrub_supers() no longer requires struct scrub_ctx * as a parameter,
>   but this should modify from scrub_supers().
> 
>   A separate patch submitted.
> 
>>       int    i;
>>       u64    bytenr;
>>       u64    gen;
>> -    int    ret;
>> +    int    ret = 0;
>> +    struct page *page;
>>       struct btrfs_fs_info *fs_info = sctx->fs_info;
>>       if (BTRFS_FS_ERROR(fs_info))
>>           return -EROFS;
>> +    page = alloc_page(GFP_KERNEL);
>> +    if (!page)
>> +        return -ENOMEM;
>> +
> 
>   Over allocation for PAGESIZE>4K is unoptimized for SB, which is
>   acceptable. Add a comment to clarify.

For this, I'm not sure if it's that unoptimized.

The "alternative" is to just allocate 4K memory, but bio needs a page 
pointer, not a memory pointer (it can be converted, but not simple if 
not aligned).

The PAGESIZE > 4K one is only not ideal for memory usage, which I'd say 
doesn't worthy a full comment.
At most an ASSERT() like "ASSERT(PAGE_SIZE >= BTRFS_SUPER_INFO_SIZE);".

Thanks,
Qu

> 
> Thanks, Anand
> 
>>       /* Seed devices of a new filesystem has their own generation. */
>>       if (scrub_dev->fs_devices != fs_info->fs_devices)
>>           gen = scrub_dev->generation;
>> @@ -4269,15 +4310,12 @@ static noinline_for_stack int 
>> scrub_supers(struct scrub_ctx *sctx,
>>           if (!btrfs_check_super_location(scrub_dev, bytenr))
>>               continue;
>> -        ret = scrub_sectors(sctx, bytenr, BTRFS_SUPER_INFO_SIZE, bytenr,
>> -                    scrub_dev, BTRFS_EXTENT_FLAG_SUPER, gen, i,
>> -                    NULL, bytenr);
>> +        ret = scrub_one_super(sctx, scrub_dev, page, bytenr, gen);
>>           if (ret)
>> -            return ret;
>> +            break;
>>       }
> 
>> -    wait_event(sctx->list_wait, atomic_read(&sctx->bios_in_flight) == 
>> 0);
> 
>   Nice.  :-)
> 
> Thanks, Anand
> 
>> -
>> -    return 0;
>> +    __free_page(page);
>> +    return ret;
>>   }
>>   static void scrub_workers_put(struct btrfs_fs_info *fs_info)
> 

  reply	other threads:[~2023-03-21  7:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20  2:12 [PATCH v3 00/12] btrfs: scrub: use a more reader friendly code to implement scrub_simple_mirror() Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 01/12] btrfs: scrub: use dedicated super block verification function to scrub one super block Qu Wenruo
2023-03-21  5:22   ` Anand Jain
2023-03-21  7:25     ` Qu Wenruo [this message]
2023-03-21 22:12       ` David Sterba
2023-03-20  2:12 ` [PATCH v3 02/12] btrfs: introduce a new helper to submit bio for scrub Qu Wenruo
2023-03-21 12:02   ` Christoph Hellwig
2023-03-24  9:58     ` Qu Wenruo
2023-03-25  8:09       ` Christoph Hellwig
2023-03-25  8:21         ` Qu Wenruo
2023-03-25  8:31           ` Christoph Hellwig
2023-03-25  8:48             ` Qu Wenruo
2023-03-27  3:36               ` Christoph Hellwig
2023-03-20  2:12 ` [PATCH v3 03/12] btrfs: introduce a new helper to submit write " Qu Wenruo
2023-03-21  0:14   ` David Sterba
2023-03-21  0:54     ` Qu Wenruo
2023-03-21  1:27       ` David Sterba
2023-03-23  8:48     ` Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 04/12] btrfs: scrub: introduce the structure for new BTRFS_STRIPE_LEN based interface Qu Wenruo
2023-03-21  0:22   ` David Sterba
2023-03-20  2:12 ` [PATCH v3 05/12] btrfs: scrub: introduce a helper to find and fill the sector info for a scrub_stripe Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 06/12] btrfs: scrub: introduce a helper to verify one metadata Qu Wenruo
2023-03-21  0:31   ` David Sterba
2023-03-20  2:12 ` [PATCH v3 07/12] btrfs: scrub: introduce a helper to verify one scrub_stripe Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 08/12] btrfs: scrub: introduce the main read repair worker for scrub_stripe Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 09/12] btrfs: scrub: introduce a writeback helper " Qu Wenruo
2023-03-21  0:43   ` David Sterba
2023-03-20  2:12 ` [PATCH v3 10/12] btrfs: scrub: introduce error reporting functionality " Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 11/12] btrfs: scrub: introduce the helper to queue a stripe for scrub Qu Wenruo
2023-03-20  2:12 ` [PATCH v3 12/12] btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure Qu Wenruo
2023-03-21  1:12   ` David Sterba
2023-03-21  0:09 ` [PATCH v3 00/12] btrfs: scrub: use a more reader friendly code to implement scrub_simple_mirror() David Sterba
2023-03-23  6:28   ` Qu Wenruo
2023-03-23 17:51     ` David Sterba
2023-03-24  0:42       ` Qu Wenruo
2023-03-27 23:28         ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16b37d65-8b90-f5b1-0f30-41cf392689a5@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.