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

ZFS for Mac OS X Breaths New Life

code.google.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: ZFS for Mac OS X Breaths New Life

#21

Post by johnthedebs »

BonoboBoner wrote: post #20

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.

Re: ZFS for Mac OS X Breaths New Life

#22

Post by johnthedebs »

wtallis wrote: post #16
ComputerGuru wrote: post #12

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

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

Re: ZFS for Mac OS X Breaths New Life

#23

Post by Someone »

ComputerGuru wrote: post #12

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

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?

Re: ZFS for Mac OS X Breaths New Life

#24

Post by johnthedebs »

Someone wrote: post #23
ComputerGuru wrote: post #12

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

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.

Re: ZFS for Mac OS X Breaths New Life

#25

Post by ComputerGuru »

johnthedebs wrote: post #22
wtallis wrote: post #16

Earlier quoted context omitted.

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

Really the biggest culprit is Mail.app - so this would depend on how big your Mail archive is.

Re: ZFS for Mac OS X Breaths New Life

#26

Post by wtallis »

johnthedebs wrote: post #22
wtallis wrote: post #16

Earlier quoted context omitted.

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

Re: ZFS for Mac OS X Breaths New Life

#27

Post by yardie »

johnthedebs wrote: post #21
BonoboBoner wrote: post #20

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.

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.

Re: ZFS for Mac OS X Breaths New Life

#28

Post by newman314 »

johnthedebs wrote: post #24
Someone wrote: post #23

Earlier quoted context omitted.

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

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.

Re: ZFS for Mac OS X Breaths New Life

#29

Post by newman314 »

wmf wrote: post #10
redial wrote: post #7

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.

Too bad. I wonder why they did not throw support after btrfs if there were licensing issues with zfs.

Re: ZFS for Mac OS X Breaths New Life

#30

Post by johnthedebs »

ComputerGuru wrote: post #25
johnthedebs wrote: post #22

Earlier quoted context omitted.

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

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

Post reply on HN