From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/4] btrfs: prepare compression for bs > ps support
Date: Wed, 10 Sep 2025 14:48:02 +0930 [thread overview]
Message-ID: <cover.1757481354.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Fix a missing callsite inside btrfs_compress_file_range() which only
zeros the range inside the first page
The folio_zero_range() of the last compressed folio should cover the
full folio, not only the first page.
This is the compression part support for bs > ps cases.
The main trick involved is the handling of compr folios, the main
changes are:
- Compressed folios now need to follow the minimal order
This is the requirement for the recently added btrfs_for_each_block*()
helpers, and this keeps our code from handling sub-block sized ranges.
- No cached compression folios for bs > ps cases
Those folios are large and are not sharable between other fses, and
most of btrfs will use 4K (until storage with 16K block size got
popular).
- Extra rejection of HIGHMEM systems with bs > ps support
Unfortunately HIGHMEM large folios need us to map them page by page,
this breaks our principle of no sub-block handling.
Considering HIGHMEM is always a pain in the backend and is already
planned for deprecation, it's best for everyone to just reject bs > ps
btrfses on HIGHMEM systems.
Please still keep in mind that, raid56, scrub, encoded write are not yet
supporting bs > ps cases.
For now I have only done basic read/write/balance/offline data check
tests on bs > ps cases with all 4 compression algorithms (none, lzo, zlib,
zstd), so far so good.
If some one wants to play with the incomplete bs > ps cases, the
following simple diff will enable the work:
--- a/fs/btrfs/fs.c
+++ b/fs/btrfs/fs.c
@@ -96,8 +96,7 @@ bool __attribute_const__ btrfs_supported_blocksize(u32 blocksize)
*/
if (IS_ENABLED(CONFIG_HIGHMEM) && blocksize > PAGE_SIZE)
return false;
- if (blocksize <= PAGE_SIZE)
- return true;
+ return true;
#endif
return false;
}
The remaining features and their road maps are:
- Encoded writes
This should be the most simple part.
- RAID56
Needs to convert the page usage into folio one first.
- Scrub
This relies on some RAID56 interfaces for parity handling.
Otherwise pretty like RAID56, we need to convert the page usage to
folios first.
Qu Wenruo (4):
btrfs: prepare compression folio alloc/free for bs > ps cases
btrfs: prepare zstd to support bs > ps cases
btrfs: prepare lzo to support bs > ps cases
btrfs: prepare zlib to support bs > ps cases
fs/btrfs/compression.c | 38 +++++++++++++++++++-------
fs/btrfs/compression.h | 2 +-
fs/btrfs/extent_io.c | 7 +++--
fs/btrfs/extent_io.h | 3 ++-
fs/btrfs/fs.c | 17 ++++++++++++
fs/btrfs/fs.h | 6 +++++
fs/btrfs/inode.c | 16 ++++++-----
fs/btrfs/lzo.c | 59 ++++++++++++++++++++++-------------------
fs/btrfs/zlib.c | 60 +++++++++++++++++++++++++++---------------
fs/btrfs/zstd.c | 44 +++++++++++++++++--------------
10 files changed, 163 insertions(+), 89 deletions(-)
--
2.50.1
next reply other threads:[~2025-09-10 5:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 5:18 Qu Wenruo [this message]
2025-09-10 5:18 ` [PATCH v2 1/4] btrfs: prepare compression folio alloc/free for bs > ps cases Qu Wenruo
2025-09-10 5:18 ` [PATCH v2 2/4] btrfs: prepare zstd to support " Qu Wenruo
2025-09-10 5:18 ` [PATCH v2 3/4] btrfs: prepare lzo " Qu Wenruo
2025-09-10 5:18 ` [PATCH v2 4/4] btrfs: prepare zlib " Qu Wenruo
2025-09-15 6:53 ` [PATCH v2 0/4] btrfs: prepare compression for bs > ps support 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.1757481354.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 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.