linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: fdmanana@kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3] btrfs: fix creation of compressed inline extents that don't save space
Date: Tue, 15 Sep 2026 07:03:31 +0930	[thread overview]
Message-ID: <733c94c9-a24d-4bce-9baa-a87f29b9deae@suse.com> (raw)
In-Reply-To: <db49ecd42bbdfb15a6e103d1e65da94cb7409543.1789414631.git.fdmanana@suse.com>



在 2026/9/15 05:10, fdmanana@kernel.org 写道:
> From: Filipe Manana <fdmanana@suse.com>
> 
> If the compressed data of an inline extent is larger than or equals to the
> size of the uncompressed data, we are still allowing the creation of the
> compressed inline extent, which does not result in any benefits, quite the
> contrary as we waste metadata space and have to decompress when reading.
> 
> This is a recent regression introduced in commit 3eaf5f082c4c ("btrfs:
> extract inlined creation into a dedicated delalloc helper").
> 
> It happens because we are passing the block size to btrfs_compress_bio(),
> so we don't get -E2BIG from the compression code anymore, but we can not
> pass i_size either, because if i_size is smaller than sector size, we
> end up never creating lzo compressed inline extent for such small i_size
> values. So refuse the compressed result at run_delalloc_inline() if
> its size is not smaller than the uncompressesed size (i_size).
> 
> Fixes: 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper")
> Reported-by: Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>
> Link: https://lore.kernel.org/linux-btrfs/c97652a5-ac6b-4de6-aa23-3cdebc01d00b@gmail.com/
> Signed-off-by: Filipe Manana <fdmanana@suse.com>

Reviewed-by: Qu Wenruo <wqu@suse.com>

Thanks,
Qu

> ---
> 
> V3: Fix being unable to create lzo compressed inline extents when the
>      data size (i_size) is smaller than the sector size (caught by
>      sashiko again).
> 
> V2: Check first if we can create an inline extent otherwise a too large
>      i_size would create a lot of work just to be discarded later.
> 
>   fs/btrfs/inode.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
> 
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index a85a7c561cf8..2b4387db937e 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -2339,12 +2339,27 @@ static int run_delalloc_inline(struct btrfs_inode *inode, struct folio *locked_f
>   		} else if (inode->prop_compress) {
>   			compress_type = inode->prop_compress;
>   		}
> +		/*
> +		 * We need to pass blocksize and not i_size, otherwise we can't
> +		 * create compressed inline extents for data smaller than sector
> +		 * size with lzo.
> +		 */
>   		cb = btrfs_compress_bio(inode, 0, blocksize, compress_type, compress_level, 0);
>   		if (IS_ERR(cb)) {
>   			cb = NULL;
>   			/* Just fall back to non-compressed case. */
>   		} else {
>   			compressed_size = cb->bbio.bio.bi_iter.bi_size;
> +			/*
> +			 * If we did not save space, it's pointless and wasteful
> +			 * to have an inline compressed extent, so fallback to
> +			 * an uncompressed inline extent.
> +			 */
> +			if (compressed_size >= i_size) {
> +				cleanup_compressed_bio(cb);
> +				cb = NULL;
> +				compressed_size = 0;
> +			}
>   		}
>   	}
>   	if (!can_cow_file_range_inline(inode, 0, i_size, compressed_size)) {


      reply	other threads:[~2026-09-14 21:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 17:36 [PATCH] btrfs: fix creation of compressed inline extents that don't save space fdmanana
2026-09-14 18:15 ` Hanabishi
2026-09-14 18:46 ` [PATCH v2] " fdmanana
2026-09-14 19:40 ` [PATCH v3] " fdmanana
2026-09-14 21:33   ` Qu Wenruo [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=733c94c9-a24d-4bce-9baa-a87f29b9deae@suse.com \
    --to=wqu@suse.com \
    --cc=fdmanana@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;
as well as URLs for NNTP newsgroup(s).