From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: support more pages sizes for the subpage support
Date: Tue, 11 Jan 2022 10:34:31 +0800 [thread overview]
Message-ID: <20220111023434.22915-1-wqu@suse.com> (raw)
The series can be fetched from github:
https://github.com/adam900710/linux/tree/metadata_subpage_switch
Previously we only support 64K page size with 4K sector size for subpage
support.
There are two reasons for such requirement:
- Make sure no matter what the nodesize is, metadata can be fit into one
page
This is to avoid multi-page metadata handling.
- We use u16 as bitmap
That means we will waste extra memory for smaller page sizes.
The 2nd problem is already solved by compacting all bitmap into one
large bitmap, in commit 72a69cd03082 ("btrfs: subpage: pack all subpage
bitmaps into a larger bitmap").
And this patchset will address the first problem by going to non-subpage
routine if nodesize >= PAGE_SIZE.
This will still leave a small limitation, that for nodesize >= PAGE_SIZE
and sectorsize < PAGE_SIZE case, we can not allow a tree block to cross
page boundary.
Thankfully we have btrfs-check to detect such problem, and mkfs and
kernel chunk allocator have already ensured all our metadata will not
cross such page boundaries.
The following combinations has been tested:
(p: page_size s: sectorsize, n: nodesize)
- p=64K s=4K n=64K (aarch64, RK3399/CM4)
To cover the new metadata path
- p=64K s=4K n=16K (aarch64, RK3399/CM4)
- p=4k s=4k n=16k (x86_64)
The make sure no new bugs in the old path
- p=16K s=4K n=16K (aarch64, M1)
- p=16K s=4K n=64K (aarch64, M1)
Special thanks to Su Yue. He contributes his VM on M1 to me to do
extra tests, and exposed a bug in the btrfs_read_sys_array() affecting
16K page size cases.
Changelog:
RFC->v1:
- Remove one ASSERT() which is causing false alert
As we have no way to distinguish unmapped extent buffer with anonymous
page used by DIO/compression.
- Expand the subpage support to any PAGE_SIZE > 4K
There is still a limitation on not allowing metadata block crossing page
boundaries, but that should already be rare nowadays.
Another limit is we still don't support 256K page size due to it's
beyond max compressed extent size.
v2:
- Add extra supported sectorsizes in sysfs interface
Now for page size > 4K, all sector sizes up to page size will be
supported.
- Fix a bug in btrfs_read_sys_array() that would cause false alert
Now btrfs_read_sys_array() will use dummy eb, and
set/clear_extent_buffer_uptodate() will handle both dummy and subpage
cases properly.
- Fix a bug in check_eb_alignment() that would cause false alert
Since we handle nodesize >= PAGE_SIZE cases with the same page based
metadata routine, we need to make sure metadata is page aligned for
that case.
Qu Wenruo (3):
btrfs: use dummy extent buffer for super block sys chunk array read
btrfs: make nodesize >= PAGE_SIZE case to reuse the non-subpage
routine
btrfs: expand subpage support to any PAGE_SIZE > 4K
fs/btrfs/disk-io.c | 20 ++++++---
fs/btrfs/extent_io.c | 102 ++++++++++++++++++++++++++++---------------
fs/btrfs/inode.c | 2 +-
fs/btrfs/subpage.c | 30 ++++++-------
fs/btrfs/subpage.h | 25 +++++++++++
fs/btrfs/sysfs.c | 11 +++--
fs/btrfs/volumes.c | 27 ++----------
7 files changed, 130 insertions(+), 87 deletions(-)
--
2.34.1
next reply other threads:[~2022-01-11 2:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 2:34 Qu Wenruo [this message]
2022-01-11 2:34 ` [PATCH v2 1/3] btrfs: use dummy extent buffer for super block sys chunk array read Qu Wenruo
2022-01-11 9:56 ` Qu Wenruo
2022-01-11 2:34 ` [PATCH v2 2/3] btrfs: make nodesize >= PAGE_SIZE case to reuse the non-subpage routine Qu Wenruo
2022-01-11 2:34 ` [PATCH v2 3/3] btrfs: expand subpage support to any PAGE_SIZE > 4K 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=20220111023434.22915-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 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).