On Fri, Sep 15, 2017 at 05:34:57PM +0200, 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. > > 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. > * btrfs: allow setting zstd level
I'll add the patches to for-next as it does not affect default behaviour and the changes are contained in compression. Further updates are fine, though I think we'll have to resolve the workspace waste before the patches can be merged to master. I tend agree to add the separator and slightly prefer ':' over '-'. In order to utilize the zstd at higher levels, we can enhance the compressed chunk size and then we could use another ':' to separate that from the rest. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
