> 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. "compresson=on" 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
