Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 RESEND 0/4] btrfs: removal of on-stack paddrs[], final part
Date: Thu, 3 Sep 2026 13:38:27 -0700	[thread overview]
Message-ID: <20260903203827.GI325502@zen.localdomain> (raw)
In-Reply-To: <cover.1787101260.git.wqu@suse.com>

On Wed, Aug 19, 2026 at 10:36:15AM +0930, Qu Wenruo wrote:
> [CHANGELOG]
> v3 RESEND:
> - Minor commit message change
>   The resend is most for proper sashiko review.
> 
> v3:
> - Rebased to the latest for-next
>   There is a fix in RAID56, which can cause conflicts with the last
>   patch
> 
> - Remove all remaining on-stack paddrs[] usage
>   There are two last ones in RAID56, one can be converted to use bio
>   interface, the other is not using on-stack paddrs[] array.
> 
>   So we can finally remove all on-stack paddrs[] usage.
> 
> 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.
> 
> 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.

This series looks really good to me overall, thanks for making this huge
API improvement.

Reviewed-by: Boris Burkov <boris@bur.io>

> 
> 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 is still one caller left:
> 
> - 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 (4):
>   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
>   btrfs: remove on-stack paddrs[] array usage
> 
>  fs/btrfs/bio.c         | 140 +++++++++++++++++++----------------------
>  fs/btrfs/bio.h         |   5 +-
>  fs/btrfs/btrfs_inode.h |  12 ++--
>  fs/btrfs/disk-io.c     |  25 +++++---
>  fs/btrfs/file-item.c   |  20 ++----
>  fs/btrfs/inode.c       | 114 +++++++++++----------------------
>  fs/btrfs/raid56.c      |  47 ++++++++------
>  7 files changed, 159 insertions(+), 204 deletions(-)
> 
> -- 
> 2.54.0
> 

      parent reply	other threads:[~2026-09-03 20:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19  1:06 [PATCH v3 RESEND 0/4] btrfs: removal of on-stack paddrs[], final part Qu Wenruo
2026-08-19  1:06 ` [PATCH v3 RESEND 1/4] btrfs: replace btrfs_repair_io_failure() to use bio for page iteration Qu Wenruo
2026-08-19  1:06 ` [PATCH v3 RESEND 2/4] btrfs: enhance btrfs_data_csum_ok() " Qu Wenruo
2026-08-19  1:06 ` [PATCH v3 RESEND 3/4] btrfs: use a shared helper to calculate data checksum for a bio Qu Wenruo
2026-08-19  1:06 ` [PATCH v3 RESEND 4/4] btrfs: remove on-stack paddrs[] array usage Qu Wenruo
2026-09-03 20:38 ` Boris Burkov [this message]

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=20260903203827.GI325502@zen.localdomain \
    --to=boris@bur.io \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /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