Le 06/07/2017 à 13:59, Austin S. Hemmelgarn a écrit : > On 2017-07-05 20:25, Nick Terrell wrote: >> On 7/5/17, 12:57 PM, "Austin S. Hemmelgarn" <ahferro...@gmail.com> >> wrote: >>> It's the slower compression speed that has me arguing for the >>> possibility of configurable levels on zlib. 11MB/s is painfully slow >>> considering that most decent HDD's these days can get almost 5-10x that >>> speed with no compression. There are cases (WORM pattern archival >>> storage for example) where slow writes to that degree may be >>> acceptable, >>> but for most users they won't be, and zlib at level 9 would probably be >>> a better choice. I don't think it can beat zstd at level 15 for >>> compression ratio, but if they're even close, then zlib would still >>> be a >>> better option at that high of a compression level most of the time. >> >> I don't imagine the very high zstd levels would be useful to too many >> btrfs users, except in rare cases. However, lower levels of zstd should >> outperform zlib level 9 in all aspects except memory usage. I would >> expect >> zstd level 7 would compress as well as or better than zlib 9 with faster >> compression and decompression speed. It's worth benchmarking to >> ensure that >> it holds for many different workloads, but I wouldn't expect zlib 9 to >> compress better than zstd 7 often. zstd up to level 12 should >> compress as >> fast as or faster than zlib level 9. zstd levels 12 and beyond allow >> stronger compression than zlib, at the cost of slow compression and more >> memory usage. > While I generally agree that most people probably won't use zstd > levels above 3, it shouldn't be hard to support them if we're going to > have configurable compression levels, so I would argue that it's still > worth supporting anyway.
One use case for the higher compression levels would be manual defragmentation with recompression for a subset of data (files that won't be updated and are stored for long periods typically). The filesystem would be mounted with a low level for general usage low latencies and the subset of files would be recompressed with a high level asynchronously. Best regards, Lionel -- 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
