Slashdot Mirror
Apple Removes Nearly All Reference To ZFS
Roskolnikov writes "Apple has apparently decided that ZFS isn't really ready for prime time. We've been discussing Apple/ZFS rumors, denials, and sightings for some years now. Currently a search on Apple's site for ZFS yields only two hits, one of them probably an oversight in the ZFS-cleansing program and the other a reference to open source. Contrast this with an item from the Google cache regarding ZFS and Snow Leopard. Apple has done this kind of disappearing act in the past, but I was really hoping that this was one feature promise they would keep. I certainly hope this isn't the first foot in the grave for ZFS on OS X."
The Known Issues and Features in the Works page for ZFS on MacOSforge explains the situation pretty well. Integrating ZFS into MacOSX isn't just a matter of creating a device driver. Time Machine, Finder, Spotlight and other core OS products needs to support ZFS features explicitly, since ZFS behaves a lot differently from HFS+.
I'm fairly confident of what it is, having actually used zfs on OS X.
Okay, first and foremost it is well known that if you are running a database engine on top of ZFS you have to tune it to that specific database engine. This is well documented, and well described in the ZFS manuals, including steps to be taken to resolve these issues.
As for the performance degradation when the disks are close to full are being worked on, while this can cause issues (especially if you have a lot of snapshots) any IT worth their salt would not have let the disk get that close to full that it causes issues (I've seen this error once on my production servers, when the disk was at 95% capacity, I was brought in as a contractor). Replacing and upgrading disk capacity is as simple as pulling one drive from the RAID Z, placing a new one in, and letting it resilver, then pull the next one, until you have pulled all of them, after which you will get the full space the new disks can provide, so going from 1 TB drives to 1.5 TB drives will at the end of replacing all of them (so that they are now all 1.5 TB or bigger) give you the extra space.
As for 1, ZFS is extremely simple to use. gvinum from FreeBSD, or Linux's LVM are complicated, unnecessarily so, and 2, ZFS has so far proven far more reliable. It has been extremely fast, and has already saved a whole lot of trouble when a disk started failing by giving us a warning that ZFS reads were failing and letting us replace the disk before disaster strikes. Since we started using it in the last year we have had not yet had to resort to finding the backup tapes for a server because a disk went bad in Linux's LVM and bad data was written to other disks and files were lost.
I don't believe the issue is that ZFS is not ready yet, I don't think that Apple has had the time to make sure that everything fits in with their way everything has to work, certain features that HFS+ can offer are not possible on ZFS yet. Certain tools are relying on very specific HFS+ mechanics and workings (Time machine for example) which would complicate work to replicate that on ZFS.
While I was looking forward to seeing ZFS in Mac OS X, I doubted that it would be anytime soon, especially since it is a large undertaking making sure that the various parts of the system are all tuned for ZFS, this includes the way the OS caches, the amount of memory it can use for ZFS arc cache, and things along those lines. FreeBSD has slowly been working through those exact issues.
cat
Mac OS X Server has a few features that are hard to replicate well on other servers, basically coming down to specific Mac management (Open Directory, NetBoot, Software Update), and in particular AFP file services. There are a lot of design/production companies out there with a lot of Macs who need a reasonable amount of storage, and AFP still tends to work better for Mac clients than things like SMB. We've got a few clients with a few hundred Macs and and ZFS would have been a good additional option to have for backend storage. The snapshot and scrub features alone would be a big benefit.
Xsan is great for certain situations but Apple's tools tend to target that towards video production, and not everyone needs or can afford a full SAN.
The iTunes store uses Akamai. So it uses Linux, not OSX at all.
We use Mac OSX Server for our infrastructure. It's a royal PITA and I now wish we hadn't done it, but there have been a number of media companies in recent years that have moved to Mac OSX Server because all their clients are OSX.
My view is that Apple is just jealous of Microsoft and said to itself that if Microsoft can drop promised new features in Vista like the DB based file system, then why can't Apple drop ZFS? ;-)
Apple uses Akamai for mirroring some of their stuff. They use Xserves as the main source.
I wouldn't think Akamai would be doing any of the actual work behind the iTunes store. I seem to recall they do have that capability, but it would be really hard to take advantage of unless you designed for it from the start, and even then I doubt anyone, especially a company as large as Apple, would be happy to give their content distribution network access to any of their actual user data.
Our website is served by Akamai as well, but nearly all the content is served by Windows web servers. If you do a simple GET and the page is in the cache of the Akamai server you're using, then you could maybe say it was served by Linux or whatever. If you do a search or anything that requires actual work, your request will be getting funneled back to our Windows servers.
I would say it's extremely unlikely iTunes works any differently.
(for those who got freaked out and wondered were they were after they clicked your link).
It's widely known that Steve Jobs and Larry Ellison are good friends, see this from http://en.wikipedia.org/wiki/Larry_Ellison
"On 18 December 2003, Ellison married Melanie Craft, a romance novelist, at his Woodside estate. His friend Steve Jobs, Apple, Inc's CEO, was the official wedding photographer."
So, no, Larry's company becoming ZFS owner ain't the reason Steve's company would drop it.
Sig erased via substitution of an identical one.
What ZFS does have that typical Apple Consumers would like to see it on desktops
Pretty much all of it applies equally to consumer systems.
ZFS is not miracle what is not possible to gain already with other kind setup with RAID and other filesystem
You need to study ZFS more, as you clearly know little about it. Almost no RAID systems can do what ZFS does. Hints: end to end checksumming; self-healing; copy on write; ...
Hint: The extra capability largely comes from integrating both the "filesystem" and "volume manager" layers, which are separate modules in traditional configurations. Calling ZFS a "filesystem" seems to mislead a lot of people that it can be compared to other "filesystems"; and the fact that ZFS implements RAID-like redundancy leads people to think that it can be compared to other "RAID" systems. Sure, it can be compared, but conventional systems will generally lose (notably in data integrity, but also in performance, manageability, etc).
you had me at #!
Shame I just blew my mod points by posting.
But parent is completely wrong. ZFS root/boot is fully supported by Sun, and ZFS itself is used in production in thousands of installations.
you had me at #!
I have been following the zfs-discuss list for years, and almost no one has lost data.
That must be a different list than the one I've been reading....
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-April/027748.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-April/027765.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-January/025601.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March/027629.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March/027365.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March/027257.html
You're right on the button. I created a sparse file for each machine image using diskutil so I could fix maximum size (I'd hate it to take over my entire 2.5 TB pool). The trick is to figure out the name that each machine wants, but worse comes to worse, you cancel it quick on the first sync if it's wrong and then rename the file and start it again.
Then I used the native CIFS service that comes with OpenSolaris for the connection. I started with Samba, but the native CIFS service had 1000X better throughput.
There is an option that enables mounting "foreign" disks for time machine. This may explain it better:
http://www.macosxhints.com/article.php?story=20080420211034137