All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/8] btrfs: scrub: support subpage scrub (completely independent version)
Date: Mon, 26 Oct 2020 15:11:07 +0800	[thread overview]
Message-ID: <20201026071115.57225-1-wqu@suse.com> (raw)

To my surprise, the scrub functionality is completely independent, thus
it can support subpage much easier than subpage read/write itself.

Thus here comes the independent scrub support for subpage.

== BACKGROUND ==
With my experimental subpage read/write, the scrub is always reporting
my subpage fs is completely corrupted, every tree block and every data
sector is corrupted.

Thus there must be something wrong with the scrub and subpage.

== CAUSE ==
It turns out that, scrub is hard coding tons of PAGE_SIZE, and always
assume PAGE_SIZE == sectorsize.
Structure scrub_page is in fact more like scrub_sector, where it only
stores one sector.

But there is also some good news, since scrub is submitting its own read
write bio, it avoids all the hassles to handle page unaligned sectors.

== WORKAROUND ==
The workaround is pretty straightforward, always store just one sector
in one scrub_page.
And teach the scrub_checksum_*() functions to follow the sector size of
each scrub_page.

The cost is pretty obvious for 64K page size systems.
If using 4K sector size, we need a full page to scrub one 4K sector.
And we will allocate 16 times more space to scrub 4K sectors compared to
4K page size systems.

But still, the cost should be more or less acceptable for now.

== TODO ==
To properly handle the case, we should get rid of scrub_page completely.

The main objective of scrub_page is just to restore the per-sector csum.
In fact all the members like logical/physical/physical_for_replace can
be calculated from scrub_block.

If we can store pages/csums/csums_bitmap in scrub_block, we can easily
do proper page based csum check for both data and metadata, and take the
advantage of much larger page size.

But that work is beyond the scope of subpage support, I will take that
work after the subpage functionality if fully completely.

== PATCHSET STRUCTURE ==
Patch 01~04:	Small refactors and cleanups spotted during the
		development.
Patch 05~08:	Support for subpage scrub.

All these patches will be also included in next subpage patchset update,
but considering they are way more independent than current subpage
patchset, it's still worthy submitting.


The support won't change anything for current sector size == PAGE_SIZE
cases.
Both 4K and 64K page systems tested.

For subpage testing, it's only basic scrub and repair tested, and there
are still some blockage for full fstests run.

Qu Wenruo (8):
  btrfs: scrub: distinguish scrub_page from regular page
  btrfs: scrub: remove the @force parameter of scrub_pages()
  btrfs: scrub: use flexible array for scrub_page::csums
  btrfs: scrub: refactor scrub_find_csum()
  btrfs: scrub: introduce scrub_page::page_len for subpage support
  btrfs: scrub: always allocate one full page for one sector for RAID56
  btrfs: scrub: support subpage tree block scrub
  btrfs: scrub: support subpage data scrub

 fs/btrfs/scrub.c | 292 +++++++++++++++++++++++++++++++----------------
 1 file changed, 192 insertions(+), 100 deletions(-)

-- 
2.29.0


             reply	other threads:[~2020-10-26  7:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26  7:11 Qu Wenruo [this message]
2020-10-26  7:11 ` [PATCH 1/8] btrfs: scrub: distinguish scrub_page from regular page Qu Wenruo
2020-10-26 14:13   ` Josef Bacik
2020-10-26  7:11 ` [PATCH 2/8] btrfs: scrub: remove the @force parameter of scrub_pages() Qu Wenruo
2020-10-26 14:20   ` Josef Bacik
2020-10-26  7:11 ` [PATCH 3/8] btrfs: scrub: use flexible array for scrub_page::csums Qu Wenruo
2020-10-26 14:23   ` Josef Bacik
2020-10-26  7:11 ` [PATCH 4/8] btrfs: scrub: refactor scrub_find_csum() Qu Wenruo
2020-10-26 14:39   ` Josef Bacik
2020-10-26  7:11 ` [PATCH 5/8] btrfs: scrub: introduce scrub_page::page_len for subpage support Qu Wenruo
2020-10-26  7:11 ` [PATCH 6/8] btrfs: scrub: always allocate one full page for one sector for RAID56 Qu Wenruo
2020-10-26  7:11 ` [PATCH 7/8] btrfs: scrub: support subpage tree block scrub Qu Wenruo
2020-10-26  7:11 ` [PATCH 8/8] btrfs: scrub: support subpage data scrub 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=20201026071115.57225-1-wqu@suse.com \
    --to=wqu@suse.com \
    --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 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.