>> If we're going to make that configurable, there are some things to
>> consider:
>>
>> * the underlying compressed format -- does not change for different
>> levels
This is true for zlib and zstd. lzo in the kernel only supports one
compression level.
>> * the configuration interface -- mount options, defrag ioctl
>>
>> * backward compatibility
> There is also the fact of deciding what to use for the default when
> specified without a level. This is easy for lzo and zlib, where we can
> just use the existing level, but for zstd we would need to decide how to
> handle a user just specifying 'zstd' without a level. I agree with E V
> that level 3 appears to be the turnover point, and would suggest using
> that for the default.
I chose level 1 because I thought if we had to choose one speed/compression
trade off, faster would be better. However, with a configerable compression
level, level 3 is a great default, and is the default of the zstd CLI.
>> So, I don't see any problem making the level configurable.
> I would actually love to see this, I regularly make use of varying
> compression both on BTRFS (with separate filesystems) and on the
> ZFS-based NAS systems we have at work (where it can be set per-dataset)
> to allow better compression on less frequently accessed data.
I would love to see configurable compression level as well. Would you want
me to add it to my patch set, or should I adapt my patch set to work on top
of it when it is ready?
