Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Use lz4 compression for metadata where available #1540

Closed
DeHackEd opened this issue Jun 21, 2013 · 6 comments
Closed

Feature: Use lz4 compression for metadata where available #1540

DeHackEd opened this issue Jun 21, 2013 · 6 comments
Labels
Type: Feature Feature request or new feature
Milestone

Comments

@DeHackEd
Copy link
Contributor

Currently metadata compression (if not disabled by the zfs_mdcomp_disable parameter) is explicitly set to LZJB. If the LZ4 feature flag is active it probably makes sense to switch to using LZ4 in its place.

See zfs/modules/zfs/dmu.c function dmu_write_policy

@behlendorf
Copy link
Contributor

It would be useful to measure if there are really any space saving to be had for metadata when using lz4 over lzjb. If the savings are minimal it may be wiser to leave it stored as lzjb which is understood by virtually all of the existing implementations.

@DeHackEd
Copy link
Contributor Author

I thought about that, especially when 4k disks make the benefits shrink. That's why I said only if the state is already active. By that time it's too late for any other implementations to be able to read it since the state is irreversible and has no compatibility support. Might as well enjoy the improved decompression speed.

I also thought about potential alternative implementations such as inheriting the compression setting from the filesystem properties, but somehow gzip-9 compressed metadata doesn't sit well with me. :)

@ryao
Copy link
Contributor

ryao commented Jun 22, 2013

@DeHackEd Nice catch. This explains why lzjb appeared to be in use on my pool where I was doing lz4. With that said, this issue also affects Illumos. It probably would make sense to discuss it with them on their mailing list.

@behlendorf The Illumos wiki might be a good reference here:

A rough comparative analysis of LZ4 performance vs. LZJB:

* Approximately 50% faster compression when operating on compressible data.
* Approximately 80% faster on decompression.
* Over three times faster on compression of incompressible data.
* Higher compression ratio (up to 10% on the larger block sizes).
* Performance on modern CPUs often exceeds 500 MB/s on compression and over 1.5 GB/s on decompression and incompressible data (per single CPU core).

http://wiki.illumos.org/display/illumos/LZ4+Compression

My understanding of lz4 versus lzjb is that lzjb would not have been invented had lz4 been available when ZFS were first made. lz4 is superior to lzjb by virtually all metrics.

@aikudinov
Copy link

illumos feature request: https://www.illumos.org/issues/3756

@maci0
Copy link
Contributor

maci0 commented Jun 22, 2013

+1

@behlendorf behlendorf removed this from the 0.7.0 milestone Oct 16, 2014
@thegreatgazoo
Copy link

Looks like it was already committed on Illumos:
illumos/illumos-gate@b8289d2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Feature request or new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants