[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aKi6J2IkGOytAggj@mozart.vkv.me>
Date: Fri, 22 Aug 2025 11:42:47 -0700
From: Calvin Owens <calvin@...nvd.org>
To: Sun YangKai <sunk67188@...il.com>
Cc: clm@...com, dsterba@...e.com, josef@...icpanda.com,
linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
neelx@...e.com, quwenruo.btrfs@....com
Subject: Re: [PATCH] btrfs: Accept and ignore compression level for lzo
On Friday 08/22 at 18:20 +0800, Sun YangKai wrote:
> > The compression level is meaningless for lzo, but before commit
> > 3f093ccb95f30 ("btrfs: harden parsing of compression mount options"),
> > it was silently ignored if passed.
> >
> > After that commit, passing a level with lzo fails to mount:
> > BTRFS error: unrecognized compression value lzo:1
> >
> > Restore the old behavior, in case any users were relying on it.
> >
> > Fixes: 3f093ccb95f30 ("btrfs: harden parsing of compression mount options")
> > Signed-off-by: Calvin Owens <calvin@...nvd.org>
> > ---
> >
> > fs/btrfs/super.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > index a262b494a89f..7ee35038c7fb 100644
> > --- a/fs/btrfs/super.c
> > +++ b/fs/btrfs/super.c
> > @@ -299,7 +299,7 @@ static int btrfs_parse_compress(struct btrfs_fs_context
> > *ctx,>
> > btrfs_set_opt(ctx->mount_opt, COMPRESS);
> > btrfs_clear_opt(ctx->mount_opt, NODATACOW);
> > btrfs_clear_opt(ctx->mount_opt, NODATASUM);
> >
> > - } else if (btrfs_match_compress_type(string, "lzo", false)) {
> > + } else if (btrfs_match_compress_type(string, "lzo", true)) {
> >
> > ctx->compress_type = BTRFS_COMPRESS_LZO;
> > ctx->compress_level = 0;
> > btrfs_set_opt(ctx->mount_opt, COMPRESS);
> >
> > --
> > 2.47.2
>
> A possible improvement would be to emit a warning in
> btrfs_match_compress_type() when @may_have_level is false but a
> level is still provided. And the warning message can be something like
> "Providing a compression level for {compression_type} is not supported, the
> level is ignored."
>
> This way:
> 1. users receive a clearer hint about what happened,
> 2. existing setups relying on this behavior continue to work,
> 3. the @may_have_level semantics remain consistent.
Thanks Sun, sorry for not acknowledging your suggestion in my last
response. Repeating what I said there: if it helps get this in, I'm
happy to do it, but it sounds like Qu is pretty fundamentally opposed
to keeping the old behavior.
>
Powered by blists - more mailing lists