From owner-freebsd-fs@FreeBSD.ORG Sat Jul 6 19:29:40 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF2D62CD for ; Sat, 6 Jul 2013 19:29:40 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from moh3-ve3.go2.pl (moh3-ve3.go2.pl [193.17.41.87]) by mx1.freebsd.org (Postfix) with ESMTP id A0BF9116D for ; Sat, 6 Jul 2013 19:29:40 +0000 (UTC) Received: from moh3-ve3.go2.pl (unknown [10.0.0.158]) by moh3-ve3.go2.pl (Postfix) with ESMTP id 92354B5A713 for ; Sat, 6 Jul 2013 21:29:39 +0200 (CEST) Received: from unknown (unknown [10.0.0.142]) by moh3-ve3.go2.pl (Postfix) with SMTP for ; Sat, 6 Jul 2013 21:29:38 +0200 (CEST) Received: from unknown [93.175.66.185] by poczta.o2.pl with ESMTP id lvlUWf; Sat, 06 Jul 2013 21:29:38 +0200 Message-ID: <51D8701E.1010209@o2.pl> Date: Sat, 06 Jul 2013 21:29:34 +0200 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130611 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, Xin Li Subject: Re: freebsd-fs Digest, Vol 524, Issue 10 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-O2-Trust: 1, 37 X-O2-SPF: neutral Cc: Volodymyr Kostyrko , d@delphij.net, marck@rinet.ru, avg@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:29:40 -0000 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 ' > 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