> 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
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