Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1710926
| From | David Sterba <dsterba@suse.cz> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v5 2/5] lib: Add zstd modules |
| Date | 2017-08-14 15:40 +0200 |
| Message-ID | <uenL3-4Jh-7@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <ucLya-7Ry-23@gated-at.bofh.it> <ucRax-2Vl-3@gated-at.bofh.it> <ud10d-1xP-5@gated-at.bofh.it> <ud1CV-1Mf-5@gated-at.bofh.it> <uenL3-4Jh-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Aug 11, 2017 at 09:20:10AM -0400, Chris Mason wrote: > > > On 08/10/2017 03:25 PM, Hugo Mills wrote: > > On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: > >> On 08/10/2017 04:30 AM, Eric Biggers wrote: > >>> > >>> Theses benchmarks are misleading because they compress the whole file as a > >>> single stream without resetting the dictionary, which isn't how data will > >>> typically be compressed in kernel mode. With filesystem compression the data > >>> has to be divided into small chunks that can each be decompressed independently. > >>> That eliminates one of the primary advantages of Zstandard (support for large > >>> dictionary sizes). > >> > >> I did btrfs benchmarks of kernel trees and other normal data sets as > >> well. The numbers were in line with what Nick is posting here. > >> zstd is a big win over both lzo and zlib from a btrfs point of view. > >> > >> It's true Nick's patches only support a single compression level in > >> btrfs, but that's because btrfs doesn't have a way to pass in the > >> compression ratio. It could easily be a mount option, it was just > >> outside the scope of Nick's initial work. > > > > Could we please not add more mount options? I get that they're easy > > to implement, but it's a very blunt instrument. What we tend to see > > (with both nodatacow and compress) is people using the mount options, > > then asking for exceptions, discovering that they can't do that, and > > then falling back to doing it with attributes or btrfs properties. > > Could we just start with btrfs properties this time round, and cut out > > the mount option part of this cycle. > > > > In the long run, it'd be great to see most of the btrfs-specific > > mount options get deprecated and ultimately removed entirely, in > > favour of attributes/properties, where feasible. > > > > It's a good point, and as was commented later down I'd just do mount -o > compress=zstd:3 or something. We've solved that already, here's a proposed patch that extends current mount options, https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg66248.html and a patch that could be backported to older kernels so the new mount options do not break mounts on older kernels with the new syntax https://patchwork.kernel.org/patch/9845697/
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCH v5 2/5] lib: Add zstd modules David Sterba <dsterba@suse.cz> - 2017-08-14 15:40 +0200
csiph-web