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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BE89F6F9-FDE9-4DE0-BED0-ED8F350895A8@meta.com>
Date: Tue, 15 Apr 2025 14:58:51 +0000
From: Nick Terrell <terrelln@...a.com>
To: Qu Wenruo <wqu@...e.com>
CC: Daniel Vacek <neelx@...e.com>, "dsterba@...e.cz" <dsterba@...e.cz>,
        Qu
 Wenruo <quwenruo.btrfs@....com>, Chris Mason <clm@...a.com>,
        Josef Bacik
	<josef@...icpanda.com>, David Sterba <dsterba@...e.com>,
        Nick Terrell
	<terrelln@...a.com>,
        "linux-btrfs@...r.kernel.org"
	<linux-btrfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] btrfs: zstd: add `zstd-fast` alias mount option for fast
 modes



> On Apr 14, 2025, at 11:50 PM, Qu Wenruo <wqu@...e.com> 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://urldefense.com/v3/__https://facebook.github.io/zstd/__;!!Bt8RZUm9aw!7KPURbKO2g65XCAyShKtwZo6K7VjTovi2iOlXsfo1zUBg-bqxGY6TFndfisxqKk_kQzI$ https://urldefense.com/v3/__https://facebook.github.io/zstd/zstd_manual.html__;!!Bt8RZUm9aw!7KPURbKO2g65XCAyShKtwZo6K7VjTovi2iOlXsfo1zUBg-bqxGY6TFndfisxqHPiTlxm$ 
>>> 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.

Upstream refers to the negative compression levels as fast levels. Both because it describes
their aim (to be fast), and because passing a negative compression level is hard in the CLI where
`zstd -1` means level 1. So the CLI says `zstd --fast=1` means level negative 1.

However, on the library side there is no "zstd-fast" concept. You just pass a negative compression
level to zstd.

Other libraries, like folly::compression, also refer to negative compression levels as ZSTD_FAST [0].
However, this is only because there were pre-existing "enum" values that assigned different semantics
to levels -1 through -3, so we couldn't just pass a negative compression level.

Overall, the concept of "fast" compression levels meaning negative levels isn't going anywhere. However,
neither is passing negative compression levels to the upstream API. Both are valid.

I'd lean towards just referring to using `zstd:-N` because it keeps the user interface smaller.

Best,
Nick Terrell


[0] https://github.com/facebook/folly/blob/5237d93b450bfd9170c4746f00aa583f0e662c2d/folly/compression/Compression.h#L113-L125
[1] https://github.com/facebook/folly/blob/5237d93b450bfd9170c4746f00aa583f0e662c2d/folly/compression/Compression.h#L446-L448

> Thanks,
> Qu
> 
>>>> We can make this change before 6.15 final so it's not in any released
>>>> kernel and we don't have to deal with compatibility.