On Tue, May 05, 2020 at 04:39:45AM +0000, Nick Terrell wrote: > > On May 4, 2020, at 6:31 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > > Looks like since zstd v1.3.4 there are five negative levels (also > > --fast levels), that looks like they'd be in the ballpark of competing > > with lz4. That might be useful even with some of the faster NVMe > > drives, ~2G/s. > > > > Any idea if it's possible or even likely? > > Zstd in the kernel would have to be updated to a newer version for this to be possible. > As zstd development slows down, I want to spend some time to update the version in > the kernel. But, I don’t expect to find the time to do this for some time. > > After that there is a limitation in the number of bits required to store the compression > Level. Last time I looked there were 15 possible values. These naturally map to > compression levels 1-15. That isn’t necessarily set in stone, but the BtrFS folks would > could answer that better. The 4 bits for level are arbitrary for now, only for in-memory tracking and not stored on-disk. Also I think that 15 levels should be enough, so even if the number can be changed I don't see it as likely. Possible improvements in the speed/ratio trade offs in the levels sound OK to me, the only constraint is to keep the default at 3 with more or less same performance/ratio. Let's say the level 1 implementation can be changed to the fast levels as mentioned above, as this still meets the user expectation of fast/lor-ratio outcome.
