Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance of Solaris' ZFS LZ4 Compression

jomasoftmarcel.blogspot.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Performance of Solaris' ZFS LZ4 Compression

#11

Post by gigatexal »

rincebrain wrote: post #10
feld wrote: post #8

Earlier quoted context omitted.

Conpression is fine. Dedup has always been the problem because it was rushed.

I don't think it's dedup being "rushed" that's a problem - implementing dedup is often done "offline" (like with NTFS's implementation, or btrfs), so the data gets written as unique at first, and then eventually something runs through, finds duplicates, and rewrites history to point all the duplicate instances to one copy. But ZFS deeply hardcodes assumptions which mean you don't get to rewrite history like that, so…

Dedup can be done right if the system has enough ram.

Re: Performance of Solaris' ZFS LZ4 Compression

#12

Post by dom0 »

gigatexal wrote: post #11
rincebrain wrote: post #10

Earlier quoted context omitted.

I don't think it's dedup being "rushed" that's a problem - implementing dedup is often done "offline" (like with NTFS's implementation, or btrfs), so the data gets written as unique at first, and then eventually something runs through, finds duplicates, and rewrites history to point all the duplicate instances to one copy. But ZFS deeply hardcodes assumptions which mean you don't get to rewrite history like that, so…

Dedup can be done right if the system has enough ram.

I don't know much about ZFS' deduplication, just heard that it requires a lot of memory, in a "hard minimum amount" way, to do it. This suggests, to me, that at least one design element of their deduplication engine is poor.

Efficient deduplication is design-wise a rather difficult problem with many trade-offs and issues which can blow your lower torso clean off when done wrong.

I don't think there is a system (beyond sheer coincidence, which seems rather unlikely given the complexity of the problem space) that can support good deduplication in an "added on later" way.

E.g. ext4 and btrfs have extent sharing which does work, but is completely inefficient (time). ZFS seems to be inefficient as well (space).

I'm off the cuff not aware of an open source deduplicating file system that does not have these issue. There are the deduplicating archivers (borg, restic, some others), but these are neither meant nor want to be general-purpose filesystems (although borg offers a ro FUSE FS with satisfactory performance).

Re: Performance of Solaris' ZFS LZ4 Compression

#13

Post by al452 »

throwaway2048 wrote: post #4
DiabloD3 wrote: post #2

Please note: Oracle does not implement the same version of ZFS as everyone else does. Sun chose the OpenZFS project as the steward of ZFS, and Oracle chose to never integrate OpenZFS upstream into their version of Solaris (which it itself is also an incompatible fork of the actual Solaris steward project, Illumos née OpenSolaris). Since OpenZFS already implements LZ4 compression (and has so for quite some time), this…

I think its a bit much to pretend that oracle somehow doesn't have "real" ZFS and solaris, even if you dont like what they have done with them and they are incompatable.

Meh. Whatever one calls "real", "incompatible with everyone else" was the real point, and it's a strong one.

Re: Performance of Solaris' ZFS LZ4 Compression

#14

Post by al452 »

throwaway2048 wrote: post #4
DiabloD3 wrote: post #2

Please note: Oracle does not implement the same version of ZFS as everyone else does. Sun chose the OpenZFS project as the steward of ZFS, and Oracle chose to never integrate OpenZFS upstream into their version of Solaris (which it itself is also an incompatible fork of the actual Solaris steward project, Illumos née OpenSolaris). Since OpenZFS already implements LZ4 compression (and has so for quite some time), this…

I think its a bit much to pretend that oracle somehow doesn't have "real" ZFS and solaris, even if you dont like what they have done with them and they are incompatable.

Meh. Whatever one calls "real", "incompatible with everyone else" was the real point, and it's a strong one.

Re: Performance of Solaris' ZFS LZ4 Compression

#15

Post by lathiat »

CJefferson wrote: post #3

This really is too brief a study (although it's obviously fine for someone to write a quick blog-post about whatever they want). Most importantly, how fast is the disk? I suspect (but would benchmark if I really needed to know) that the effects of compressions will be greatly different on an older 7,200 rpm spinning disk, vs a modern SSD.

It's a very good question because his copies are stupidly slow. Only 15MB/s. You could probably compress that in real time on a raspberry Pi!

It's a very poor test.

Re: Performance of Solaris' ZFS LZ4 Compression

#16

Post by lathiat »

feld wrote: post #8
gtirloni wrote: post #7

It must be fine on a small test system, with CPU idling, etc. I've worked with a few "ZFS appliances" from Sun (256-512TB range, NFS/iSCSI shares, 1-2k clients) and would never enable any advanced features on those (compression, dedup, etc). They were awfully unstable when we did that. Granted, that was 5 years ago but I don't see any indication this technology has evolved significantly with all the drama surrounding…

Conpression is fine. Dedup has always been the problem because it was rushed.

Totally correct. In most scenarios dedup is simply unworkable. And the main source of problems.

Compression on the other hand is very standard and no issue at all, from many many years of ZFS experience. It's the default in many cases (ie on Nexenta)

Re: Performance of Solaris' ZFS LZ4 Compression

#17

Post by STRML »

lathiat wrote: post #16
feld wrote: post #8

Earlier quoted context omitted.

Conpression is fine. Dedup has always been the problem because it was rushed.

Totally correct. In most scenarios dedup is simply unworkable. And the main source of problems. Compression on the other hand is very standard and no issue at all, from many many years of ZFS experience. It's the default in many cases (ie on Nexenta)

And on many cloud systems, especially those with network disks like EBS, compression gives you some serious avg throughput wins.

Re: Performance of Solaris' ZFS LZ4 Compression

#18

Post by herf »

Most people say lz4+ZFS is a net win and you should usually enable it by default.

The big "gap" is probably between lz4 and gzip. e.g., for compressing logs, where gzip compresses a lot more but is terribly slow.

I hope zstd could be used for this case someday: http://facebook.github.io/zstd/

Re: Performance of Solaris' ZFS LZ4 Compression

#19

Post by feld »

rincebrain wrote: post #10
feld wrote: post #8

Earlier quoted context omitted.

Conpression is fine. Dedup has always been the problem because it was rushed.

I don't think it's dedup being "rushed" that's a problem - implementing dedup is often done "offline" (like with NTFS's implementation, or btrfs), so the data gets written as unique at first, and then eventually something runs through, finds duplicates, and rewrites history to point all the duplicate instances to one copy. But ZFS deeply hardcodes assumptions which mean you don't get to rewrite history like that, so…

Dedup was rushed. This is supported by the original authors. I believe it was discussed in detail in a presentation by Matthew Ahrens. If I could remember the specific source I would link it, but it did not get the same level of testing and care as other features.

Re: Performance of Solaris' ZFS LZ4 Compression

#20

Post by dmit »

herf wrote: post #18

Most people say lz4+ZFS is a net win and you should usually enable it by default. The big "gap" is probably between lz4 and gzip. e.g., for compressing logs, where gzip compresses a lot more but is terribly slow. I hope zstd could be used for this case someday: http://facebook.github.io/zstd/

I imagine zstd's license will hamper its corporate adoption, especially among the big players.

  The license granted hereunder will terminate,
  automatically and without notice, if you (or any
  of your subsidiaries, corporate affiliates or
  agents) initiate directly or indirectly, or take
  a direct financial interest in, any Patent
  Assertion: (i) against Facebook or any of its
  subsidiaries or corporate affiliates...
https://github.com/facebook/zstd/blob/dev/PATENTS
Post reply on HN