linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH 0/4] btrfs: refactor scrub entrances for each profile
Date: Wed, 19 Jan 2022 13:52:25 +0800	[thread overview]
Message-ID: <12e31a86-79b6-d806-f232-51e9bb0a7e07@suse.com> (raw)
In-Reply-To: <20220107023430.28288-1-wqu@suse.com>

Hi David,

Any plan to merge this patchset?

And if you need, I can merge all these refactors into one branch for you 
to fetch.

I know this sounds terrifying especially after the autodefrag "refactor" 
disaster, but unlike autodefrag, scrub/replace has existing test case 
coverage and this time it's really refactor, no behavior change (at 
least no intentional one).

I hope to get a stable base for the incoming scrub_page/scrub_bio 
structure cleanup.

As there is some plan to make scrub to use page::index for those 
anonymous pages, so they don't need to rely on bi_private to get their 
logical bytenr, and hopefully just one structure, scrub_range, to 
replace the scrub_page/scrub_bio things.

Thanks,
Qu

On 2022/1/7 10:34, Qu Wenruo wrote:
> The branch is based on several recent submitted small cleanups, thus
> it's better to fetch the branch from github:
> 
> https://github.com/adam900710/linux/tree/refactor_scrub
> 
> [CRAP-BUT-IT-WORKS(TM)]
> 
> Scrub is one of the area we seldom touch because:
> 
> - It's a mess
>    Just check scrub_stripe() function.
>    It's a function scrubbing a stripe for *all* profiles.
> 
>    It's near 400 lines for a single complex function, with double while()
>    loop and several different jumps inside the loop.
> 
>    Not to mention the lack of comments for various structures.
> 
>    This should and will never happen under our current code standard.
> 
> - It just works
>    I have hit more than 10 bugs during development, and I just want to
>    give up the refactor, as even the code is crap, it works, passing the
>    existing scrub/replace group.
>    While no matter how small code change I'm doing, it always fails to pass
>    the same tests.
> 
> [REFACTOR-IDEA]
> 
> The core idea here, is to get rid of one-fit-all solution for
> scrub_stripe().
> 
> Instead, we explicitly separate the scrub into 3 groups (the idea is
> from my btrfs-fuse project):
> 
> - Simple-mirror based profiles
>    This includes SINGLE/DUP/RAID1/RAID1C* profiles.
>    They have no stripe, and their repair is purely mirror based.
> 
> - Simple-stripe based profiles
>    This includes RAID0/RAID10 profiles.
>    They are just simple stripe (without P/Q nor rotation), with extra
>    mirrors to support their repair.
> 
> - RAID56
>    The most complex profiles, they have extra P/Q, and have rotation.
> 
> [REFACTOR-IMPLEMENTATION]
> 
> So we have 3 entrances for all those supported profiles:
> 
> - scrub_simple_mirror()
>    For SINGLE/DUP/RAID1/RAID1C* profiles.
>    Just go through each extent and scrub the extent.
> 
> - scrub_simple_stripe()
>    For RAID0/RAID10 profiles.
>    Instead we go each data stripe first, then inside each data stripe, we
>    can call scrub_simple_mirror(), since after stripe split, RAID0 is
>    just SINGLE and RAID10 is just RAID1.
> 
> - scrub_stripe() untouched for RAID56
>    RAID56 still has all the complex things to do, but they can still be
>    split into two types (already done by the original code)
> 
>    * data stripes
>      They are no different in the verification part, RAID56 is just
>      SINGLE if we ignore the repair path.
>      It's only in repair path that our path divides.
> 
>      So we can reuse scrub_simple_mirror() again.
> 
>    * P/Q stripes
>      They already have a dedicated function handling the case.
> 
> With all these refactors, although we have several more functions, we
> get rid of:
> 
> - A double while () loop
> - Several jumps inside the double loop
> - Complex calculation to try to fit all profiles
> 
> And we get:
> 
> - Better comments
> - More dedicated functions
> - A better basis for further refactors
> 
> [INCOMING CLEANUPS]
> 
> - Use find_first_extent_item() to cleanup the RAID56 code
>    This part itself can be as large this patchset already, thus will be
>    in its own patchset.
> 
> - Refactor scrub_pages/scrub_parity/... structures
> 
> Qu Wenruo (4):
>    btrfs: introduce a helper to locate an extent item
>    btrfs: introduce dedicated helper to scrub simple-mirror based range
>    btrfs: introduce dedicated helper to scrub simple-stripe based range
>    btrfs: use scrub_simple_mirror() to handle RAID56 data stripe scrub
> 
>   fs/btrfs/scrub.c | 702 ++++++++++++++++++++++++++++-------------------
>   1 file changed, 422 insertions(+), 280 deletions(-)
> 


  parent reply	other threads:[~2022-01-19  5:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07  2:34 [PATCH 0/4] btrfs: refactor scrub entrances for each profile Qu Wenruo
2022-01-07  2:34 ` [PATCH 1/4] btrfs: introduce a helper to locate an extent item Qu Wenruo
2022-01-07  2:34 ` [PATCH 2/4] btrfs: introduce dedicated helper to scrub simple-mirror based range Qu Wenruo
2022-01-07  2:34 ` [PATCH 3/4] btrfs: introduce dedicated helper to scrub simple-stripe " Qu Wenruo
2022-01-07  2:34 ` [PATCH 4/4] btrfs: use scrub_simple_mirror() to handle RAID56 data stripe scrub Qu Wenruo
2022-01-07 14:44 ` [PATCH 0/4] btrfs: refactor scrub entrances for each profile David Sterba
2022-01-19  5:52 ` Qu Wenruo [this message]
2022-01-24 20:24   ` David Sterba
2022-01-25  0:06     ` Qu Wenruo
2022-01-25  5:47       ` Qu Wenruo

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=12e31a86-79b6-d806-f232-51e9bb0a7e07@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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 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).