public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: linux-block@vger.kernel.org
Subject: [PATCH 0/9] btrfs: used compressed_bio structure for writes
Date: Mon, 26 Jan 2026 09:18:39 +1030	[thread overview]
Message-ID: <cover.1769381237.git.wqu@suse.com> (raw)

Cc: linux-block@vger.kernel.org

Cc bio people first, there are some uncertain/tricky usage of the bio
structure:

- Is it a good idea to queue unaligned range into a bio?

  Bio means Block IO, but bio_add_*() never requires alignment (to 512
  bytes), so not sure if this is expected or not.
  Only the bi_sector is sector related.

  Thus this patch is queuing a lot of unaligned range into a bio,
  especially for LZO cases.
  (ZLIB and ZSTD are properly filling all folios except the last one)

  But the end result should still be fine, most ranges (except the last
  block) will be properly merged and fill a full folio.
  Most unaligned parts will only be temporary before merge.

  Btrfs internally has extra alignment checks thus an unaligned 
  bio will never be submitted.

- Will there be a public helper to "round up" a bio

  Since we have unaligned bios, we will need to round them up before
  submission.
  For now I'm using internal helpers to do that, but a public helper
  will be appreciated.

The remaining part are all btrfs specific.

I was never a huge fan of the current btrfs_compress_folios() interface:

- Complex and duplicated parameter list

  * A folio array to hold all folios
    Which means extra error handling.

  * A @nr_folios pointer
    That pointer is both input and output, representing the number of max
    folios, but also the number of compressed folios.

    The number of input folios is not really necessary, it's always no
    larger than DIV_ROUND_UP(len, PAGE_SIZE) in the first place.

  * A @total_in pointer
    Again an pointer as both input and output, representing the filemap
    range length, and how many bytes are compressed in this run.

    However if we failed to compress the full range, all supported
    algorithms will return an error, thus fallback to uncompressed path.

    Thus there is no need to use it as an output pointer.

  * A @total_compressed point
    Again an pointer as both input and output, representing the max
    number of compressed size, and the final compressed size.

    However we do not need it as an input at all, we always error out
    if the compressed size is larger than the original size.

- Extra error cleanup handling

  We need to cleanup the compressed_folios[] array during error
  handling.

Replace the old btrfs_compress_folios() interface with
btrfs_compress_bio(), which has the following benefits:

- Simplified parameter list

  * inode
  * start
  * len
  * compress_type
  * compress_level 
  * write_flags

    No parameter is sharing input and output members, and all are very
    straightforward (except the last write_flags, which is just an extra
    bio flag).

- Directly return a compressed_bio structure

  With minor modifications, that pointer can be passed to
  btrfs_submit_bio().

  The caller still needs to do proper round up and fill the proper
  disk_bytenr/num_bytes before submission.

  And for error handling, simply call cleanup_compressed_bio() then
  everything is cleaned up properly (at least I hope so).

- No more extra folios array passing and error handling


Qu Wenruo (9):
  btrfs: introduce lzo_compress_bio() helper
  btrfs: introduce zstd_compress_bio() helper
  btrfs: introduce zlib_compress_bio() helper
  btrfs: introduce btrfs_compress_bio() helper
  btrfs: switch to btrfs_compress_bio() interface for compressed writes
  btrfs: remove the old btrfs_compress_folios() infrastructures
  btrfs: get rid of compressed_folios[] usage for compressed read
  btrfs: get rid of compressed_folios[] usage for encoded writes
  btrfs: get rid of compressed_bio::compressed_folios[]

 fs/btrfs/compression.c | 205 +++++++++++++++++--------------------
 fs/btrfs/compression.h |  40 ++++----
 fs/btrfs/inode.c       | 217 ++++++++++++++++++++-------------------
 fs/btrfs/lzo.c         | 223 +++++++++++++++++++++++++++--------------
 fs/btrfs/zlib.c        |  64 ++++++------
 fs/btrfs/zstd.c        |  69 ++++++-------
 6 files changed, 434 insertions(+), 384 deletions(-)

-- 
2.52.0


             reply	other threads:[~2026-01-25 22:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-25 22:48 Qu Wenruo [this message]
2026-01-25 22:48 ` [PATCH 1/9] btrfs: introduce lzo_compress_bio() helper Qu Wenruo
2026-01-25 22:48 ` [PATCH 2/9] btrfs: introduce zstd_compress_bio() helper Qu Wenruo
2026-01-26  2:53   ` Qu Wenruo
2026-01-25 22:48 ` [PATCH 3/9] btrfs: introduce zlib_compress_bio() helper Qu Wenruo
2026-01-25 22:48 ` [PATCH 4/9] btrfs: introduce btrfs_compress_bio() helper Qu Wenruo
2026-01-25 22:48 ` [PATCH 5/9] btrfs: switch to btrfs_compress_bio() interface for compressed writes Qu Wenruo
2026-01-26  0:12   ` Qu Wenruo
2026-01-25 22:48 ` [PATCH 6/9] btrfs: remove the old btrfs_compress_folios() infrastructures Qu Wenruo
2026-01-25 22:48 ` [PATCH 7/9] btrfs: get rid of compressed_folios[] usage for compressed read Qu Wenruo
2026-01-25 22:48 ` [PATCH 8/9] btrfs: get rid of compressed_folios[] usage for encoded writes Qu Wenruo
2026-01-25 22:48 ` [PATCH 9/9] btrfs: get rid of compressed_bio::compressed_folios[] 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.1769381237.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-block@vger.kernel.org \
    --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