From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/7] btrfs: make subpage handling be feature full
Date: Mon, 24 Feb 2025 10:16:15 +1030 [thread overview]
Message-ID: <cover.1740354271.git.wqu@suse.com> (raw)
[CHANGLOG]
v1:
- Merge previous two patches into one
- Re-order the patches so preparation/fixes are always before feature
enablement
- Update the commit message of the first patch
So that we do not focus on the out-of-tree part, but explain why it's
not ideal in the first place (double page zeroing), and just mention
the behavior change in the future.
Since the introduction of btrfs subapge support in v5.15, there are
quite some limitations:
- No RAID56 support
Added in v5.19.
- No memory efficient scrub support
Added in v6.4.
- No block perfect compressed write support
Previously btrfs requires the dirty range to be fully page aligned, or
it will skip compression completely.
Added in v6.13.
- Various subpage related error handling fixes
Added in v6.14.
- No support to create inline data extent
- No partial uptodate page support
This is a long existing optimization supported by EXT4/XFS and
is required to pass generic/563 with subpage block size.
The last two are addressed in this patchset.
And since all features are implemented for subpage cases, the long
existing experimental warning message can be dropped, as it is already
causing a lot of concerns for users who checks the dmesg carefully.
Qu Wenruo (7):
btrfs: prevent inline data extents read from touching blocks beyond
its range
btrfs: fix the qgroup data free range for inline data extents
btrfs: introduce a read path dedicated extent lock helper
btrfs: make btrfs_do_readpage() to do block-by-block read
btrfs: allow buffered write to avoid full page read if it's block
aligned
btrfs: allow inline data extents creation if block size < page size
btrfs: remove the subpage related warning message
fs/btrfs/defrag.c | 2 +-
fs/btrfs/direct-io.c | 2 +-
fs/btrfs/disk-io.c | 5 -
fs/btrfs/extent_io.c | 224 +++++++++++++++++++++++++++++++++++-----
fs/btrfs/file.c | 9 +-
fs/btrfs/inode.c | 34 +++---
fs/btrfs/ordered-data.c | 29 ++++--
fs/btrfs/ordered-data.h | 3 +-
8 files changed, 239 insertions(+), 69 deletions(-)
--
2.48.1
next reply other threads:[~2025-02-23 23:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-23 23:46 Qu Wenruo [this message]
2025-02-23 23:46 ` [PATCH 1/7] btrfs: prevent inline data extents read from touching blocks beyond its range Qu Wenruo
2025-02-25 15:07 ` Filipe Manana
2025-02-25 16:10 ` Filipe Manana
2025-02-23 23:46 ` [PATCH 2/7] btrfs: fix the qgroup data free range for inline data extents Qu Wenruo
2025-02-25 15:11 ` Filipe Manana
2025-02-23 23:46 ` [PATCH 3/7] btrfs: introduce a read path dedicated extent lock helper Qu Wenruo
2025-02-25 17:05 ` Filipe Manana
2025-02-25 21:12 ` Qu Wenruo
2025-02-25 23:44 ` Qu Wenruo
2025-02-26 11:07 ` Filipe Manana
2025-02-26 11:07 ` Filipe Manana
2025-02-23 23:46 ` [PATCH 4/7] btrfs: make btrfs_do_readpage() to do block-by-block read Qu Wenruo
2025-02-25 17:09 ` Filipe Manana
2025-02-23 23:46 ` [PATCH 5/7] btrfs: allow buffered write to avoid full page read if it's block aligned Qu Wenruo
2025-02-25 17:55 ` Filipe Manana
2025-02-25 21:16 ` Qu Wenruo
2025-02-23 23:46 ` [PATCH 6/7] btrfs: allow inline data extents creation if block size < page size Qu Wenruo
2025-02-25 18:03 ` Filipe Manana
2025-02-23 23:46 ` [PATCH 7/7] btrfs: remove the subpage related warning message Qu Wenruo
2025-02-25 18:10 ` Filipe Manana
2025-02-25 21:19 ` 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=cover.1740354271.git.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