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 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.