So ZFS dedup is a complete lose. What about compression?
Compression is a hands-down win. LZ4 compression should be on by default for nearly anything you ever set up under ZFS. I typically have LZ4 on even for datasets that will house database binaries… yes, really. Let’s look at two quick test runs, on a Xeon E3 server with 32GB ECC RAM and a pair of Samsung 850 EVO 1TB disks set up as a mirror vdev.
This is an inline compression torture test: we’re reading pseudorandom data (completely incompressible) and writing it to an LZ4 compressed dataset.
root@lab:/data# pv < in.rnd > incompressible/out.rnd 7.81GB 0:00:22 [ 359MB/s] [==================================>] 100% root@lab:/data# zfs get compressratio data/incompressible NAME PROPERTY VALUE SOURCE data/incompressible compressratio 1.00x -
359MB/sec write… yyyyyeah, I’d say LZ4 isn’t hurting us too terribly here – and this is a worst case scenario. What about something a little more realistic? Let’s try again, this time with a raw binary of my Windows Server 2012 R2 “gold” image (the OS is installed and Windows Updates are applied, but nothing else is done to it):
root@lab:/data/test# pv < win2012r2-gold.raw > realworld/win2012r2-gold.out 8.87GB 0:00:17 [ 515MB/s] [==================================>] 100%
Oh yeah – 515MB/sec this time. Definitely not hurting from using our LZ4 compression. What’d we score for a compression ratio?
root@lab:/data# zfs get compressratio data/realworld NAME PROPERTY VALUE SOURCE data/realworld compressratio 1.48x -
1.48x sounds pretty good! Can we see some real numbers on that?
root@lab:/data# ls -lh /data/realworld/win2012r2-gold.raw -rw-rw-r-- 1 root root 8.9G Feb 24 18:01 win2012r2-gold.raw root@lab:/data# du -hs /data/realworld 6.2G /data/realworld
8.9G of data in 6.2G of space… with sustained writes of 515MB/sec.
What if we took our original 8G of incompressible data, and wrote it to an uncompressed dataset?
root@lab:/data# zfs create data/uncompressed root@lab:/data# zfs set compression=off data/uncompressed root@lab:/data# cat 8G.in > /dev/null ; # this is to make sure our source data is preloaded in the ARC root@lab:/data# pv < 8G.in > uncompressed/8G.out 7.81GB 0:00:21 [ 378MB/s] [==================================>] 100%
So, our worst case scenario – completely incompressible data – means a 5% performance hit, and a more real-world-ish scenario – copying a Windows Server installation – means a 27% performance increase. That’s on fast solid state, of course; the performance numbers will look even better on slower storage (read: spinning rust), where even worst-case writes are unlikely to slow down at all.
Yep, that’s a win.
