Date: Sat, 06 Jul 2013 21:29:34 +0200 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= <radiomlodychbandytow@o2.pl> To: freebsd-fs@freebsd.org, Xin Li <delphij@delphij.net> Cc: Volodymyr Kostyrko <c.kworr@gmail.com>, d@delphij.net, marck@rinet.ru, avg@FreeBSD.org Subject: Re: freebsd-fs Digest, Vol 524, Issue 10 Message-ID: <51D8701E.1010209@o2.pl> In-Reply-To: <mailman.12354.1373020257.2328.freebsd-fs@freebsd.org> References: <mailman.12354.1373020257.2328.freebsd-fs@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/07/2013 12:30, freebsd-fs-request@freebsd.org wrote: > On 7/4/13 1:44 PM, Volodymyr Kostyrko wrote: >> > 04.07.2013 23:36, Xin Li wrote: >>> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >> >>> >> On 7/4/13 1:27 PM, Volodymyr Kostyrko wrote: >>>> >>> 04.07.2013 19:02, Andriy Gapon wrote: >>>>> >>>> on 04/07/2013 18:57 Volodymyr Kostyrko said the following: >>>>>> >>>>> Yes. Much better in terms of speed. >>>>> >>>> >>>>> >>>> And compression too. >>>> >>> >>>> >>> Can't really say. >>>> >>> >>>> >>> When the code first appeared in stable I moved two of my >>>> >>> machines (desktops) to LZ4 recreating each dataset. To my >>>> >>> surprise gain at transition from lzjb was fairly minimal and >>>> >>> sometimes LZ4 even loses to lzjb in compression size. However >>>> >>> better compression/decompression speed and moreover earlier >>>> >>> takeoff when data is incompressible clearly makes lz4 a >>>> >>> winner. >>> >> >>> >> I'm interested in this -- what's the nature of data on that >>> >> dataset (e.g. plain text? binaries? images?) >> > >> > Triple no. Biggest difference in lzjb favor was at zvol with Mac OS >> > X Snow Leo. >> > >> > Maybe it's just because recordsize is too small on zvols? Anyway >> > the difference was like a 1% or 2%. Can't remember but can retest. > Hmm that's weird. I haven't tried Mac iSCSI volumes but do have tried > Windows iSCSI volumes, and lz4 was a win. > > It may be helpful if you can post your 'zfs get all <zvol name here>' > output so we can try to reproduce the problem at lab? I guess this is mostly about record size. LZJB seems to have been designed for 4K buffers, works well for 8K, but then compression ratio basically flats out, which is why in general it performs badly. LZ4 has been designed for megabytes of data (no more no less) and while it scales well to 128K, they are rather close at 8K and I don't find it surprising that LZJB wins from time to time. https://extrememoderate.wordpress.com/2011/08/14/synthetic-test-of-filesystem-compression-part-1/ -- Twoje radio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51D8701E.1010209>