Date: Wed, 10 Jul 2013 17:43:01 +0300 From: Volodymyr Kostyrko <c.kworr@gmail.com> To: d@delphij.net Cc: freebsd-fs@FreeBSD.org, Dmitry Morozovsky <marck@rinet.ru>, Andriy Gapon <avg@FreeBSD.org> Subject: Re: ZFS default compression algo for contemporary FreeBSD versions Message-ID: <51DD72F5.8090008@gmail.com> In-Reply-To: <51D5E42C.5010506@delphij.net> References: <alpine.BSF.2.00.1307041620420.2446@woozle.rinet.ru> <51D576E1.6030803@gmail.com> <alpine.BSF.2.00.1307041950400.2446@woozle.rinet.ru> <51D59B6C.5030600@gmail.com> <51D59C88.9060403@FreeBSD.org> <51D5DAB9.4070507@gmail.com> <51D5DCDF.2030503@delphij.net> <51D5DEC4.2000101@gmail.com> <51D5E42C.5010506@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
05.07.2013 00:07, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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? Sorry, my virtual machines are all phased out so can't reproduce. At most I can see this now with this two pools: arcade@ar1l0u\/home/arcade# zfs get all ar1l0u/vbox_mac_0_cp NAME PROPERTY VALUE SOURCE ar1l0u/vbox_mac_0_cp type volume - ar1l0u/vbox_mac_0_cp creation ср лип 10 11:55 2013 - ar1l0u/vbox_mac_0_cp used 18,2G - ar1l0u/vbox_mac_0_cp available 13,0G - ar1l0u/vbox_mac_0_cp referenced 18,2G - ar1l0u/vbox_mac_0_cp compressratio 1.11x - ar1l0u/vbox_mac_0_cp reservation none default ar1l0u/vbox_mac_0_cp volsize 30G local ar1l0u/vbox_mac_0_cp volblocksize 8K - ar1l0u/vbox_mac_0_cp checksum sha256 inherited from ar1l0u ar1l0u/vbox_mac_0_cp compression lzjb local ar1l0u/vbox_mac_0_cp readonly off default ar1l0u/vbox_mac_0_cp copies 1 default ar1l0u/vbox_mac_0_cp refreservation none default ar1l0u/vbox_mac_0_cp primarycache metadata local ar1l0u/vbox_mac_0_cp secondarycache all default ar1l0u/vbox_mac_0_cp usedbysnapshots 0 - ar1l0u/vbox_mac_0_cp usedbydataset 18,2G - ar1l0u/vbox_mac_0_cp usedbychildren 0 - ar1l0u/vbox_mac_0_cp usedbyrefreservation 0 - ar1l0u/vbox_mac_0_cp logbias throughput local ar1l0u/vbox_mac_0_cp dedup off default ar1l0u/vbox_mac_0_cp mlslabel - ar1l0u/vbox_mac_0_cp sync standard default ar1l0u/vbox_mac_0_cp refcompressratio 1.11x - ar1l0u/vbox_mac_0_cp written 18,2G - ar1l0u/vbox_mac_0_cp logicalused 20,2G - ar1l0u/vbox_mac_0_cp logicalreferenced 20,2G - arcade@ar1l0u\/home/arcade# zfs get all ar1l0u/vbox_mac_1 NAME PROPERTY VALUE SOURCE ar1l0u/vbox_mac_1 type volume - ar1l0u/vbox_mac_1 creation ср чер 26 18:02 2013 - ar1l0u/vbox_mac_1 used 5,48G - ar1l0u/vbox_mac_1 available 13,0G - ar1l0u/vbox_mac_1 referenced 18,0G - ar1l0u/vbox_mac_1 compressratio 1.09x - ar1l0u/vbox_mac_1 origin ar1l0u/vbox_mac_0@xcode - ar1l0u/vbox_mac_1 reservation none default ar1l0u/vbox_mac_1 volsize 30G local ar1l0u/vbox_mac_1 volblocksize 8K - ar1l0u/vbox_mac_1 checksum sha256 inherited from ar1l0u ar1l0u/vbox_mac_1 compression lz4 inherited from ar1l0u ar1l0u/vbox_mac_1 readonly off default ar1l0u/vbox_mac_1 copies 1 default ar1l0u/vbox_mac_1 refreservation none default ar1l0u/vbox_mac_1 primarycache metadata local ar1l0u/vbox_mac_1 secondarycache all default ar1l0u/vbox_mac_1 usedbysnapshots 0 - ar1l0u/vbox_mac_1 usedbydataset 5,48G - ar1l0u/vbox_mac_1 usedbychildren 0 - ar1l0u/vbox_mac_1 usedbyrefreservation 0 - ar1l0u/vbox_mac_1 logbias throughput local ar1l0u/vbox_mac_1 dedup off default ar1l0u/vbox_mac_1 mlslabel - ar1l0u/vbox_mac_1 sync standard default ar1l0u/vbox_mac_1 refcompressratio 1.13x - ar1l0u/vbox_mac_1 written 5,48G - ar1l0u/vbox_mac_1 logicalused 5,98G - ar1l0u/vbox_mac_1 logicalreferenced 20,2G - The latter is actually a clone of some other pool so I'm not sure whether this a result of working with snapshots or a real compression difference. -- Sphinx of black quartz, judge my vow.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51DD72F5.8090008>