Performance of Solaris' ZFS LZ4 Compression

Please note: Oracle does not implement the same version of ZFS as everyone else does. Sun chose the OpenZFS project as the steward of ZFS, and Oracle chose to never integrate OpenZFS upstream into their version of Solaris (which it itself is also an incompatible fork of the actual Solaris steward project, Illumos née OpenSolaris).<p>Since OpenZFS already implements LZ4 compression (and has so for quite some time), this is yet another feature that, once enabled, will stop you from importing your incompatible pool into anything that actually implements ZFS.

This really is too brief a study (although it&#x27;s obviously fine for someone to write a quick blog-post about whatever they want).<p>Most importantly, how fast is the disk? I suspect (but would benchmark if I really needed to know) that the effects of compressions will be greatly different on an older 7,200 rpm spinning disk, vs a modern SSD.

Most people say lz4+ZFS is a net win and you should usually enable it by default.<p>The big &quot;gap&quot; is probably between lz4 and gzip. e.g., for compressing logs, where gzip compresses a <i>lot</i> more but is terribly slow.<p>I hope zstd could be used for this case someday: <a href="http:&#x2F;&#x2F;facebook.github.io&#x2F;zstd&#x2F;" rel="nofollow">http:&#x2F;&#x2F;facebook.github.io&#x2F;zstd&#x2F;</a>

It must be fine on a small test system, with CPU idling, etc.<p>I&#x27;ve worked with a few &quot;ZFS appliances&quot; from Sun (256-512TB range, NFS&#x2F;iSCSI shares, 1-2k clients) and would never enable any advanced features on those (compression, dedup, etc). They were awfully unstable when we did that.<p>Granted, that was 5 years ago but I don&#x27;t see any indication this technology has evolved significantly with all the drama surrounding Oracle, licensing, forks, etc. Just not worth the trouble these days, IMHO.