Re: [RFC 0/3]: settable compression level for zstd

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-09-15 11:34, Adam Borowski wrote:
> Hi!
> Here's a patch set that allows changing the compression level for zstd,
> currently at mount time only.  I've played with it for a month, so despite
> being a quick hack, it's reasonably well tested.  Tested on 4.13 +
> btrfs-for-4.14 only, though -- I've booted 11th-day-of-merge-window only an
> hour ago on one machine, no explosions yet.
> 
> As a quick hack, it doesn't conserve memory as it should: all workspace
> allocations assume level 15 and waste space otherwise.
> 
> Because of an (easily changeable) quirk of compression level encoding, the
> max is set at 15, but I guess higher levels are pointless for 128KB blocks.
> Nick and co can tell us more -- for me zstd is mostly a black box so it's
> you who knows anything about tuning it.
I've got limited knowledge of the zstandard algorithm, but based on my 
(probably incomplete and possibly inaccurate) analysis of the code in 
the kernel, I think this assessment is correct.  At a minimum, higher 
levels are likely to provide no benefit considering how slow things get 
(even the speed of level 15 means it's probably not going to be used much).
> 
> There are three patches:
> * [David Sterba] btrfs: allow to set compression level for zlib
>    Unmodified version of the patch from Jul 24, I'm re-sending it for
>    convenience.
> * btrfs: allow setting zlib compression level via :9
>    Some bikeshedding: it looks like Chris Mason also favours zlib:9 over
>    zlib9 as the former is more readable.  If you disagree... well, it's up
>    to you to decide anyway.  This patch accepts both syntaxes.
On this in particular, I think there _might_ be a potential issue with 
option parsing, I'd advocate something less likely to be a metacharacter 
(like '-') instead of ':', but I do agree that it's a bit more concise 
when the algorithm and level are separate.
> * btrfs: allow setting zstd level