All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Calvin Owens <calvin@wbinvd.org>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	Daniel Vacek <neelx@suse.com>, David Sterba <dsterba@suse.com>,
	Josef Bacik <josef@toxicpanda.com>, Chris Mason <clm@fb.com>
Subject: Re: [PATCH] btrfs: Accept and ignore compression level for lzo
Date: Fri, 22 Aug 2025 20:45:47 +0200	[thread overview]
Message-ID: <20250822184547.GX22430@suse.cz> (raw)
In-Reply-To: <aKg4PcgUCvXblVCY@mozart.vkv.me>

On Fri, Aug 22, 2025 at 02:28:29AM -0700, Calvin Owens wrote:
> On Friday 08/22 at 17:57 +0930, Qu Wenruo wrote:
> > 在 2025/8/22 17:15, Calvin Owens 写道:
> > > The compression level is meaningless for lzo, but before commit
> > > 3f093ccb95f30 ("btrfs: harden parsing of compression mount options"),
> > > it was silently ignored if passed.
> > 
> > Since LZO doesn't support compression level, why providing a level parameter
> > in the first place?
> 
> Interpreting "no level" as "level is always one" doesn't seem that
> unreasonable to me, especially since it has worked forever.

As it currently works, no level means use the default, which is defined
for all compression. For LZO it's implicit and 1.

> > I think it's time for those users to properly update their mount options.
> 
> It's a user visable regression, and fixing it has zero possible
> downside. I think you should take my patch :)

I tend to agree this is a usability regression, even if LZO is a bit odd
with levels, accepting the allowed values should work.

The mount options and level combinations that should work:

- compress=NAME   - use default level for NAME
- compress=NAME:0 - use default, while accepting the level setting
- compress=NAME:N - if N is in the allowed range for NAME then take it

The syntax is consistent for all three compressions.

  parent reply	other threads:[~2025-08-22 18:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22  7:45 [PATCH] btrfs: Accept and ignore compression level for lzo Calvin Owens
2025-08-22  8:27 ` Qu Wenruo
2025-08-22  9:28   ` Calvin Owens
2025-08-22 10:18     ` Qu Wenruo
2025-08-22 18:45     ` David Sterba [this message]
2025-08-22 21:42       ` Calvin Owens
2025-08-22 10:20 ` Sun YangKai
2025-08-22 10:23   ` Qu Wenruo
2025-08-22 15:54     ` Calvin Owens
2025-08-22 18:57       ` David Sterba
2025-08-22 21:44       ` Qu Wenruo
2025-08-22 23:24         ` Calvin Owens
2025-08-22 23:39           ` Qu Wenruo
2025-08-24 15:58             ` Calvin Owens
2025-08-24 21:40               ` Qu Wenruo
2025-08-25  8:51               ` Daniel Vacek
2025-08-25  9:03                 ` Qu Wenruo
2025-08-25 11:37                   ` Filipe Manana
2025-08-22 18:42   ` Calvin Owens

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=20250822184547.GX22430@suse.cz \
    --to=dsterba@suse.cz \
    --cc=calvin@wbinvd.org \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neelx@suse.com \
    --cc=quwenruo.btrfs@gmx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.