From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: removal of on-stack paddrs[], part 1
Date: Thu, 2 Jul 2026 20:43:32 +0930 [thread overview]
Message-ID: <cover.1782990655.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Fix a missing assignment for metadata repair
The logical should be assigned before passing it to
btrfs_repair_bbio_failure().
- Move the commit message of error message change to the correct patch
It's changed in the first patch not the last one.
Since the experimental bs > ps support, several on-stack fixed paddrs[]
arrays are introduced, for assemble mutli-page sized fs blocks.
However that on-stack memory usage is always there for 4K page sized
systems, no matter if the block size of the filesystem.
This series is part 1 of such on-stack paddrs[] cleanup.
The idea is to use bio interface for page iterations, the core idea is
to use a const bvec_iter as the pointer to where the block is.
Then we save a local bevc_iter, and use the local iter to check the next
few pages until we fill a full block.
Furthermore, with the help of bvec_iter, we can remove a lot of
parameters:
- file_offset
- logical
- bio_offset
All can be generated by using the @iter passed in and the
bbio->saved_iter to calculate the old @bio_offset.
@bio_offset is the (iter.bi_sector - saved_iter.bi_sector) <<
SECTOR_SHIFT.
As when bvec_iter is advanced, its bi_sector is also increased.
@logical is simpler, just iter.bi_sector << SECTOR_SHIFT.
@file_offset is the bbio->file_offset + bio_offset.
This means we no longer need to use on-stack paddrs[] to csum
generation.
With bio interfaces, the iteration of an fs block is as simple as the
following: (I tried to change the page/pg_off/cur_len into a macro just
like btrfs_bio_for_each_block(), but failed)
u32 cur = 0;
btrfs_csum_init(&cctx, fs_info->csum_type);
while (cur < blocksize) {
struct page *page = bio_iter_page(&bbio->bio, iter);
const u32 pg_off = bio_iter_offset(&bbio->bio, iter);
const u32 cur_len = min(bio_iter_len(&bbio->bio, iter), blocksize - cur);
void *kaddr;
kaddr = kmap_local_page(page) + pg_off;
btrfs_csum_update(&cctx, kaddr, cur_len);
kunmap_local(kaddr);
bio_advance_iter_single(&bbio->bio, &iter, cur_len);
cur += cur_len;
}
btrfs_csum_final(&cctx, csum);
However there are still some callers left:
- Scrub
That's already addressed in another series accidentially
(https://lore.kernel.org/linux-btrfs/cover.1782795330.git.wqu@suse.com/)
That will be last user of btrfs_check_block_csum().
- RAID56
That will be only location left without a bio.
In that case we can easily craft a local helper to do csum generation
without using on-stack paddrs[].
Qu Wenruo (3):
btrfs: replace btrfs_repair_io_failure() to use bio for page iteration
btrfs: enhance btrfs_data_csum_ok() to use bio for page iteration
btrfs: use a shared helper to calculate data checksum for a bio
fs/btrfs/bio.c | 140 +++++++++++++++++++----------------------
fs/btrfs/bio.h | 5 +-
fs/btrfs/btrfs_inode.h | 6 +-
fs/btrfs/disk-io.c | 25 +++++---
fs/btrfs/file-item.c | 19 ++----
fs/btrfs/inode.c | 59 ++++++++++++++---
6 files changed, 141 insertions(+), 113 deletions(-)
--
2.54.0
next reply other threads:[~2026-07-02 11:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 11:13 Qu Wenruo [this message]
2026-07-02 11:13 ` [PATCH v2 1/3] btrfs: replace btrfs_repair_io_failure() to use bio for page iteration Qu Wenruo
2026-07-02 11:13 ` [PATCH v2 2/3] btrfs: enhance btrfs_data_csum_ok() " Qu Wenruo
2026-07-02 11:13 ` [PATCH v2 3/3] btrfs: use a shared helper to calculate data checksum for a bio 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.1782990655.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