ZFS for Mac OS X Breaths New Life(code.google.com)
code.google.com
ZFS for Mac OS X Breaths New Life
http://code.google.com/p/maczfs/
10 comments
What I'm actually more interested in is what Apple is intending on using instead of ZFS.
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.
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.
AFAIk the main argument against use of ZFS is that it would be relatively resource hungry, making it a bad candidate for use in e.g. A MacBook Air. I have Googled, but couldn't find recent data about this. Does anybody know about any? If performance isn't good enough on some target hardware, could one do better, or would it require dropping features? Which ones?
Without encryption, compression, or deduplication on I don't think there would be very much overheard - more than traditional file systems, definitely, but still relatively very little.
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.
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.
With new Core iX processers now being able to do AES in hardware, I wonder if the CPU requirement for encryption will go down significantly once/if support is enabled.
ZFS lets you put encryption/compression/dedupe on a per filesystem basis, and filesystems are extremely light and easy to create in ZFS (one/multiple per home directory or installed app is normal) so it's easy enough to only apply those features where they're needed.
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.
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.
ZFS will also verify the checksum of each data block, which means that by default it is not a zero-copy filesystem. sendfile(), recvfile(), etc. will all require at least one read pass.
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.
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.
I don't know how resource hungry ZFS is, but the problem would be with the iOS devices, not MacBook Air.
Don't forget about the block-level deduplication and copy-on-write which would make Time Machine use much less space.
I recently got Time Machine working on a network drive that was ZFS underneath (deduplication turned on) and it didn't make a very big difference.
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).
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).
Deduplication matters most for people who edit big files. In my case, I have some virtual machines with hard drive images stored on my main filesystem. If I didn't exclude them from Time Machine, they would completely fill my backup drive in a matter of days, but with block-level deduplication, there would only be slight overhead compared with storing the same data directly on the HFS+ file system instead of in the images.
Really the biggest culprit is Mail.app - so this would depend on how big your Mail archive is.
The reason deduplication won't help much with large mail archives is that it operates at the block level. In order to be effective, you need to have two copies of the same data that are also divided along the same block boundaries (the second part is arguably the bigger problem).
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
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
You're missing my point: it's not duplicate blocks in a single mail archive that I'm concerned about, it's duplicate blocks across multiple versions of the same mail archive.
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.
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.
I'm admittedly not an expert, but isn't that a very different scenario?
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.
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.
Hasn't Mail.app been using maildirs for years? They should be pretty Time-Machine-friendly.
Time Machine uses hard links within it's directory structure, so dedupe or CoW wouldn't be much help unless it was redesigned using ZFS specific features (ie, instead of rebuilding an entire hard link structure as TM does, you'd clone the TM filesystem, then apply the source changes).
"Breaths new life" is a bit misleading' no? From the project page: "this code project will be used to record issues and ongoing development (if any) of this extension"
As well, only a single commit to the git repo since July. :(
As well, only a single commit to the git repo since July. :(
Depends on which one you're looking at. Alex's repo has a tremendous amount of work. I've been doing little work since the initial build and installer since work picked up.
I went ahead and merged mine up.
I went ahead and merged mine up.
Ah, I see now. Hiding on the "untested" branch. :-)
Sorry for any confusion then, and I stand corrected.
Sorry for any confusion then, and I stand corrected.
I was so excited to see just how alive this is! I was hunting around and about to start the project myself when I saw this and thought everyone else would be so excited to see that a package release was just put out a few hours ago. Great to see and I think that with some support we can really help these guys along and all really enjoy some wonderful fruit.
the forum is very active, especially alex blewitt. There are fairly infrequent updates, but it's definiatly being developed.
For those (like me) who are clueless on what ZFS is, the wiki page has a good overview:
In computing, ZFS is a combined file system
and logical volume manager designed by Sun
Microsystems. The features of ZFS include
data integrity (protection against bit rot,
etc), support for high storage capacities,
integration of the concepts of filesystem
and volume management, snapshots and
copy-on-write clones, continuous integrity
checking and automatic repair, RAID-Z and
native NFSv4 ACLs.
ZFS is really cool. The best things that stood out out to me when I researched it a bit a while ago (though there is so much cool about it) are
1) 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…
1) 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…
The best feature is that you can tell it to do a "zpool scrub poolname" and it will go through the entire set of drives in that pool and check the checksums, correcting as necessary. Given that there are errors that can occur silently, ZFS can detect and correct them if they are single-bit errors.
Does anyone know if Oracle is still developing ZFS, or just Btrfs? Has the situation changed so that Apple may include it on next iterations of OS X, or are we stuck with HSF+ forever?
ZFS development continues; they recently released encryption support. Based on the rumors, it sounds like Apple is now writing their own filesystem.
ZFS is more appropriate for servers; I suspect we'll see some developments in the filesystem area later this year as Mac OS X 10.7 "Lion" gets closer to shipping.
ZFS is wonderful for workstations. It keeps redundant copies of blocks and has parity functionality to keep you from having silent corruption and allowing a bad drive to sneak up on you. Running a consulting business I see many hundreds of computers yearly come in with just this problem alone for hard drive failure and ZFS would make everyone's lives so much happier just on workstations alone.
ZFS runs amazingly well on FreeBSD at the moment. Very, very stable and incredible. I love having to not worry about bad blocks / sectors anymore! I also love raid-z2 which allows 2 failed drives simultaneously. Just an amazing comfort. We can see this on Mac OS X with some effort!
ZFS is fantastic; it was my file system when I ran Solarid on my Sun workstation (until I replaced it with Ubuntu).
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/[email protected]/msg0...
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/[email protected]/msg0...
What I am interested in is, are there any ZFS patents that Oracle could use to sue Apple once they eventually broadly ship ZFS?
Apple won't be broadly shipping ZFS, which they made pretty clear when they pulled it from Snow Leopard.
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.
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.
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.
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.
It's not CDDL - Apple has shipped dtrace for years now which is CDDL code.
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.
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.
I think a side community project is perfect given this potential concern (even though likelihood is unlikely). Oracle's not going to sue Apple for something like this.
Does this support newer zfs and zpool versions? (newer version = more features)
Here's a list of where other platforms are at: http://en.wikipedia.org/wiki/ZFS#Comparisons
Here's a list of where other platforms are at: http://en.wikipedia.org/wiki/ZFS#Comparisons
I'll be that guy.
breath = noun breathe = verb
"Breathes" New Life
That is all. :)
breath = noun breathe = verb
"Breathes" New Life
That is all. :)
Very exciting!