ZFS for Mac OS X Breaths New Life (code.google.com)
I'm not sure how many folks have been mourning the seeming loss of ZFS for Mac OS X for as long as I have... but I thought that this was not only great news, but a tremendous opportunity for folks to really pitch in and help a very worthwhile project for those who value their data!
Very exciting!
44 comments
[ 2.9 ms ] story [ 123 ms ] thread1) more storage than you could ever possibly use–you won't run out. 2) you can add and remove drives on the fly. 3) you don't have drives you mount, you have pools you can add to and remove from (on the fly). 4) great redundancy/error-checking built in, in all forms.
I'd love to see it on the Mac, officially…
As well, only a single commit to the git repo since July. :(
I went ahead and merged mine up.
Sorry for any confusion then, and I stand corrected.
Here's a list of where other platforms are at: http://en.wikipedia.org/wiki/ZFS#Comparisons
All indications are that ZFS will not be the next filesystem for OS X, yet they'll need to replace HFS soon seeing as it's the worst-performing and fewest-featured filesystem in use with this generation of operating systems. HFS+ is showing its age in multiple places, and Apple could really take advantage of some of the newer features available in modern filesystems to make a huge difference and increase the power and performance behind some of the current features (a la Time Machine), with techniques such as snapshots, transactioned reads/writes, and more.
Deduplication would be nice, but I think it won't show a lot of benefit under many common workloads. Also, it can use up a ton of memory for larger drives (it would be a huge boon for SSDs, though).
Also, many applications will already try avoiding duplicate data to varying degrees which makes dedup even less beneficial (backup utilities, VCSes, etc).
If you are dealing with a lot of text, though (like in a mail archive, or with lots of source code) compression really shines. It has way less memory overhead, pretty low CPU overhead, and it can significantly increase disk throughput.
You'll notice I was careful to say "under many common workloads" in my other post, it was because of all this. For most people, most of the time, there would just be no real benefit and a decent performance hit with dedup.
Edit: to clarify
New mails are typically appended to the end of the archive, but the rest of it remains more or less the same across versions.
Also, a well-written block-level deduplication algorithm will work regardless of boundary shifts. I designed and wrote the proprietary blocklevel algorithm used in Genie Timeline, and can tell you that it saves terabytes of data in corporations for just PSTs alone. And it doesn't rely on block boundaries, capable of detecting slided or shifted data.
In other words, ZFS operates on blocks at a block level - it can't make any assumptions about the contents other than "this block is the same as this block" or "this block is not the same as this block." It can't (based on my understanding) realize that "this block is almost the same as this block" and shift things accordingly, because then it would be messing with application data that might be corrupted by the changes.
If the application is making those shifts on the other hand, it would work just fine because the application could be smart enough to shuffle and unshuffle things in the most efficient way it knows how, but the file system doesn't have the luxury.
If I'm still missing something, please let me know. Anyway, it'd be pretty straightforward to properly test this so maybe I'll do that.
Encryption would require significantly more CPU (http://forums.freebsd.org/showthread.php?t=9886)
Compression would require moderately more CPU (depends heavily on the compression algorithm) though you can actually speed up disk access with this - which is the real bottleneck (http://blogs.sun.com/observatory/entry/zfs_compression_a_win...)
Deduplication requires lots of memory (I think I saw 1-2GB per TB of data quoted someplace) and will increase CPU load a bit, but for certain workloads can save a lot of writing and diskspace (think Virtual Images or a dataset like Dropbox's).
I'm not involved in ZFS development (just an avid user) so take this with a grain of salt.
As ZFS checksums every block in the CPU anyway, doing an additional crypto step isn't all that bad, especially in a server environment where there cores are plentiful.
This isn't necessarily a bad thing--in my experience, ZFS has caught on-disk bit rot several times. However, it may not be worth it on an iPhone or other low-power device. Fortunately, it can be disabled.
They haven't made an official statement, but the general consensus is that they couldn't agree on licensing terms with Sun (ZFS is licensed under the CDDL) and so they bailed on it. Oh how I wish they had worked things out.
That said, Oracle is also unlikely to do them any favors.
You can always hope. It's not like Ellison and Jobs aren't BFFs. Oracle did write a version of their DB engine for OSX server for no, discernable, reason at all. I don't remember any customers asking for it particularly so this decision had to come down from way up top.
Most likely, ZFS was written off for various technical reasons (large RAM requirements to run well, not optimized for portable hardware, etc.) and if there was a legal issue it was probably the NetApp lawsuit against Sun regarding ZFS.
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
Gold autumn, personality Mes clothing + Shoes, Travel bag that grabs an eye coat + Chao packet Free transport
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
=== http://goo.gl/l5v0b ====
I did get bitten once, wiping out a whole bunch of data very unexpectedly, which I thought was a great ZFS weakness - http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg0...
breath = noun breathe = verb
"Breathes" New Life
That is all. :)