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