Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/2] btrfs: remove the tailing zeros from compressed inline extents
Date: Mon, 21 Sep 2026 08:20:42 +0930	[thread overview]
Message-ID: <cover.1789944508.git.wqu@suse.com> (raw)

[CHANGELOG]
v2:
- Remove the block based space saving checks completely from lzo
  Zlib and ZSTD do not have block based space saving in the first place.
  It's the caller's responsibility to check, and inlined and regular
  extents have different requirements.

  This simplify the first patch a lot.

- Update the cover letter
  Filipe's v3 fix is already merged, so we can not force push a fix but
  to co-operate the v3 fix.

Commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated
delalloc helper") changed the compression input from [0, i_size) to [0,
blocksize), which caused two problems:

- Other tools unable to decompress the inlined extent
  U-boot and btrfs-restore are affected, as they only allocated a buffer
  which is @ram_bytes sized.
  That buffer is too small to contain the decompressed data, which is
  @sectorsize.

  Those projects are fixed to have a more robust decompression routine
  which can handle both cases now.

- Worse ratio for those compressed inline extent.

  For the same 3K 0xcd filled range, the results are small but
  observable, 48 vs 61 bytes.

Filipe's v1 fix is very close to a proper fix, but btrfs will unable to
create inlined extents for lzo.
It turns out to be another bug in the copy_compressed_data_to_bio()
function.

Which is doing a premature block size based space saving checks,
meanwhile all other algorithms do not have block sized based checks, but
only a simple "@compressed >= @input" check.
Zlib and Zstd all rely on the caller to do proper space saving checks,
as regular and inlined extents have different requirements.

So this series is to properly fix the bug, firstly fix the lzo
regression which prevents inlined extent creation, then restore the old
i_size based inline extent creation.

Qu Wenruo (2):
  btrfs: lzo: fix space saving checks
  btrfs: remove the trailing zeros from compressed inline extent

 fs/btrfs/inode.c | 7 +------
 fs/btrfs/lzo.c   | 5 +++--
 2 files changed, 4 insertions(+), 8 deletions(-)

-- 
2.55.0


             reply	other threads:[~2026-09-20 22:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 22:50 Qu Wenruo [this message]
2026-09-20 22:50 ` [PATCH v2 1/2] btrfs: lzo: fix space saving checks Qu Wenruo
2026-09-20 22:50 ` [PATCH v2 2/2] btrfs: remove the trailing zeros from compressed inline extent 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.1789944508.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