linux-kernel - Re: [PATCH] btrfs: zstd: add `zstd-fast` alias mount option for fast modes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250415165623.GI16750@suse.cz>
Date: Tue, 15 Apr 2025 18:56:23 +0200
From: David Sterba <dsterba@...e.cz>
To: Qu Wenruo <wqu@...e.com>
Cc: Daniel Vacek <neelx@...e.com>, Qu Wenruo <quwenruo.btrfs@....com>,
	Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
	David Sterba <dsterba@...e.com>, Nick Terrell <terrelln@...com>,
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: zstd: add `zstd-fast` alias mount option for fast
 modes

On Tue, Apr 15, 2025 at 01:20:15PM +0930, Qu Wenruo wrote:
> 在 2025/4/14 16:23, Daniel Vacek 写道:
> > On Wed, 2 Apr 2025 at 16:31, Daniel Vacek <neelx@...e.com> wrote:
> [...]
> >> I'd still opt for keeping full range and functionality including
> >> negative levels using the plain `zstd:N` option and having the other
> >> just as an additional alias (for maybe being a bit nicer to some
> >> humans, but not a big deal really and a matter of preference).
> >> Checking the official documentation, it still mentions "negative
> >> compression levels" being the fast option.
> >>
> >> https://facebook.github.io/zstd/
> >> https://facebook.github.io/zstd/zstd_manual.html
> >>
> >> The deprecation part looks like just some gossip. It looks more about
> >> the cli tool api and we are defining a kernel mount api - perfectly
> >> unrelated.
> > 
> > Any feedback, Dave? I tend to drop this ida of `zstd-fast` alias.
> 
> Not Dave here, but if the future of "zstd-fast" is not that clear, we 
> can definitely wait for a while.
> 
> It's always safer to adapt when the terminology is mature enough.

Thanks all for the feedback, OK let's put it on hold.