> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
> I really hope someone better versed in compression - like Saso -
> would chime in to say whether gzip-9 vs. lzjb (or lz4) sucks in
> terms of read-speeds from the pools. My HDD-based assumption is
> in general that the less data you read (or write) on platters -
> the better, and the spare CPU cycles can usually take the hit.

Oh, I can definitely field that one - 
The lzjb compression (default compression as long as you just turn compression 
on without specifying any other detail) is very fast compression, similar to 
lzo.  It generally has no noticeable CPU overhead, but it saves you a lot of 
time and space for highly repetitive things like text files (source code) and 
sparse zero-filled files and stuff like that.  I personally always enable this. 

zlib (gzip) is more powerful, but *way* slower.  Even the fastest level gzip-1 
uses enough CPU cycles that you probably will be CPU limited rather than IO 
limited.  There are very few situations where this option is better than the 
default lzjb.

Some data (anything that's already compressed, zip, gz, etc, video files, 
jpg's, encrypted files, etc) are totally uncompressible with these algorithms.  
If this is the type of data you store, you should not use compression.

Probably not worth mention, but what the heck.  If you normally have 
uncompressible data and then one day you're going to do a lot of stuff that's 
compressible...  (Or vice versa)...  The compression flag is only used during 
writes.  Once it's written to the pool, compressed or uncompressed, it stays 
that way, even if you change the flag later.

zfs-discuss mailing list

Reply via email to