Slashdot Log In
Apple Looking at ZFS For Mac OS X
Posted by
Hemos
on Mon May 01, 2006 07:59 AM
from the only-the-shadow-knows dept.
from the only-the-shadow-knows dept.
Udo Schmitz writes "Apples Filesystem Development Manager, Chris Emura, is looking into porting Sun Microsystems' file system ZFS to OS X. At least this is what Sun's Eric Kustarz states on the ZFS mailing list. Is this a glimpse of hope for all those of us who think HFS+ isn't up to par for a 21st century OS? Next thing you know and they'll rewrite the Finder ..."
Related Stories
[+]
Slashback: Moon Footage, KillerNic, ZFS Leopard 207 comments
Slashback tonight brings some clarifications and updates to previous Slashdot stories including: some direct answers to Slashdot questions on the KillerNIC, recap in stolen laptop identity theft problems, a victory for one PayPal user, missing moon footage surfaces, Dell laptops unwelcome on Quantas flights, and more ZFS news from the Leopard front Read on for details.
[+]
Apple: ZFS Shows Up in New Leopard Build 351 comments
Udo Schmitz writes "As a follow-up to rumours from May this year, World of Apple has a screenshot showing Sun's Zettabyte File System in "the most recent Build of Mac OS X 10.5 Leopard". Though I still wonder: If it is not meant to replace HFS+, could there be any other reasons to support ZFS?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Comparison of Filesystems. (Score:5, Informative)
The main advantage for HFS+ users (I mean who's really going to need a 16,000,000 Gigabyte file) would be the introduction of journalling beyond metadata (and even this is unlikely to be useful to most people).
Re:Comparison of Filesystems. (Score:5, Interesting)
Imagine being able to take really fast working copies of whatever you're doing and be able to simple use the old versions by cd'ing to the old clone.
That's certainly what I would use ZFS for. The rest of the stuff, pooling and mirroring and stuff is less interesting in my laptop. :-)
Parent
Re:Comparison of Filesystems. (Score:2, Interesting)
Re:Comparison of Filesystems. (Score:3, Interesting)
I would love for the FS to do snapshot saves with incrementals and checkpoints and rollback, instead of having each application do it. This provides unlimited undos potential with actual stored versions... a true 'history' of the file, availab
ZFS on a {Power|Mac}Book{| Pro} (Score:3, Insightful)
Quite to the contrary! The most unreliable element in your laptop is your drive. It will fail at some point, have no doubts about it. ZFS will detect silent failures through its checksumming.
ZFS also makes it possible to do super-fast backups to external disk. Combine that with snapshots and you have the kind of data security enterprises pay a whole lot of money for. Here's how it works:
Re:Think you'll get it? (Score:3, Interesting)
Thanks to this, a lot of interesting stuff becomes possible, such as the fast file system creation which is demonstrated in this very cool demo [opensolaris.org].
If you don't consider ZFS a qua
Re:Think you'll get it? (Score:4, Interesting)
I can tell you grew up in the UNIX world. Everything I read about ZFS reminds me very much of VMS. Twenty years ago. If you read the UNIX Hater Handbook (published 12 years ago), then you will find a very nice rant about how the UNIX concept of partitions is a huge step back from what VMS offered. Now, over a decade later, it seems someone has listened.
Parent
Re:Think you'll get it? (Score:5, Informative)
And yes, I know that Windows NT is sort of descended from VMS. But I've not seen many of the concepts make it up to userland cleanly implemented.
And I'm also aware that VMS is still around. It may not be on life-support yet, but it's clearly in the nursing home already.
Parent
Re:Think you'll get it? (Score:3, Insightful)
I think part of what makes this story so interesting is that despite the past few years' developments, most of us still expect Apple to act as it used to with regard to adopting new technology. In
Re:Think you'll get it? (Score:4, Funny)
I guess it worked [apple.com].
Parent
Re:Comparison of Filesystems. (Score:2)
Re:Comparison of Filesystems. (Score:2)
If ZFS is included, it may be a sign that Apple is considering a bigger plunge into the enterprise markets because that seems to be where ZFS can shine. They are big in the storage markets with XServe RAID enclosures, both drive capacities and even orders seem to be going up.
Re:Comparison of Filesystems. (Score:3, Funny)
I mean who's really going to need a 16,000,000 Gigabyte file
Actually, I keep an archive of all Slashdot dupes...
beyond RAID in data integrity, self-healing (Score:3, Informative)
Re:Comparison of Filesystems. (Score:5, Informative)
Parent
Re:Comparison of Filesystems. (Score:5, Interesting)
Talking in depth to one of the original OS X engineers (there were 4 or 5 depending if you count Jobs as one of them -- they all claimed Jobs gave as much input to the original porting of Next to the new OSX as anyone else did), his claim was that fragmentation isn't a problem.
Apple specifically doesn't offer tools because it defrags files as it makes sense to the operating system -- and generally doesn't defrag at all except for tiny files because modern drive and multiple independent read / write heads on drives today make a bit of entropy a good thing. If I remember later conversations correctly, he also mentioned that Apple had several graphic based disc tools that could do the same things that the OS does on an individual file basis, but didn't see the point in releasing them because this was something that should be left up to the OS and not up to the user. I argued that the user should have control and he countered with the fact that unless you had intimate knowledge about the drives physical features as well as the OSs specific needs, you are more likely going to slow things down in your quest to align the pretty colors together on your defrag program.
What was interesting was that he also recommended that you never fill a drive past 60 or 70 %. The claim was that having a huge chunk of empty space allowed the OS to do its thing without having to resort to smoke and mirrors.
Note -- defragging is an IMPORTANT part to my audience. I deal with musicians and engineers working on digital audio workstations. I remember using specific defraggers that were used solely for our industry (i.e., would write audio files to areas of the disc that were claimed to be the fastest read / write). I followed this skeptically -- until my contact forwarded me to a counterpart of his at Microsoft that essentially said the same thing -- in a MODERN OS using modern hardware, this does more harm than good.
Do I believe that a user couldn't get more optimized use out of defragging their own drives? I don't really know...but I'm going to trust these guys. Do your own research though. For all I know, I was told a line of BS that is intended to keep people like me from poking around under 'modern os`s'
Parent
Re:Comparison of Filesystems. (Score:4, Informative)
That said, most desktop users will not notice a big difference between a fragmented, quick-defragment (defrag files, but don't consolidate free space) and full defragmented disk. A typical modern HDD has a 35-40MB/s minimum transfer rate. DV, probably the most resource intensive any normal person bothers with has a measly 25Mb/s = 3,2MB/s. Unless you're suffering from really horrible fragmentation, that should be no problem. Same goes for analog capture with hardware/on-the-fly compression. Yes, there are fringe areas like raw analog video or scientific data but audio capture isn't part of it anymore. And if you're that specific, using a separate tool isn't that big a deal. Servers OTOH might be something, but I imagine most of that is handled by other parts than the OS disk I/O.
Parent
Re:Comparison of Filesystems. (Score:4, Informative)
If you keep around 70% of your drive free, the machine will be able to make large enough chunks that given a combinations of other factors it was meaningless.
It was said with multiple independent read write heads, you can actually fill the buffer faster by spreading the load out in noncontiguous sections...and even if it did need to read sequential sections from the same head in different areas, both that the drive can read files nonsequentially and load these chunks into the cache while the other read head is catching up -- and that it takes less than a ms to jump from one sector to another these days.
The clue that was beaten into me was to think of this as sorta a spanned raid within a single drive and that's entirely how these work these days (and then told its entirely not like a raid so I shouldn't use that metaphor lest some nerd that thinks with his head instead of his gut tells me that I'm wrong -- ok I made up the last part, but its essentially what I was told).
But all in all, as other have mentioned, HSF+ likes to defrag on the fly non-contiguous chunks of less than 20 megs (and it will also do this in the background after the CPU is more free after seeing these) -- and given that the average cache on a drive is around 16 Megs, even when this inevitably doubles in the next year or two, the logic remains that this is still good enough.
But you are entirely right -- if drives didn't employ caching and multiple independent read write heads (i.e., early multiple platter systems required that the read/write heads all be driven by the same motor and thus killing any attainable speeds).
Blah blah blah...its all pseudoscience and phrenology to me. I'm just mouthing everything that was sent to me without understanding a word of it. I'm a musician (and technically a pseudoscientist by trade) so making up words and using them incorrectly by mirroring others comes naturally and might even make sense to those that don't know any better
Parent
Great if it's true (Score:2)
Re:Great if it's true (Score:2)
Re:Great if it's true (Score:2)
That's one of the differences between being a company and being an open source project. For a company, it does matter; supporting every filesystem under the sun is a detriment, not a benefit, because there are real incremental costs for each additional one you add.
Re:Great if it's true (Score:3, Insightful)
Supporting lots of filesystems is hard. Mistakes are difficult to track down and harshly punished, licenses and API's generally aren't amenable to straight ports, and it's a lot of work for what's typically a fairly small ROI. Also, porting one filesystem doesn't generally make porting another significantly easier. You might as well ask:
"But why just a skyscraper? Why not add a warehouse or a subterranean bu
Slashdot is Getting Better Again (Score:4, Interesting)
Beats the heck out of story about a blog posting that's just a regurgitation of an MSNBC article that doesn't know what the frack it's talking about.
This is meaningless (Score:5, Insightful)
There are many reasons why Apple might be looking at ZFS. Only one is that Apple intends to actually make Mac OS X use it as a home filesystem.
Now, here's a reason the write-up author didn't think of: Apple is rumoured to be working on a virtualization layer for OS X, with the intent being that OS X will run in parallel with multiple operating systems. Even if that rumour is false, it's clear that with BootCamp, Apple is taking the idea of Macs running multiple operating systems (albeit not at the same time...) seriously. Solaris and GNU/Linux are the two most popular Intel platforms save for Mac OS X and Windows.
Isn't it more likely that Apple wants Mac OS X its multi-OS Macs to "just work" with the other operating systems, able to achieve a high degree of interoperability without forcing the other platforms to support HFS+?
I'm not saying a move to ZFS would be a bad thing, though it doesn't, so far as I can see, support arbitrary metadata so it'd be as practical as UFS in its current form, which is barely used by Mac users. I just think a port of the main Solaris file systems is, in practice, something Apple would be doing anyway, as part of the Intel OS-agnostic direction they're going in.
Re:This is meaningless (Score:5, Informative)
Here is the ars technica low-down on what ZFS does differently and why that's such a good thing.
arstechnica.com/news.ars/post/20051117-5595.html [arstechnica.com]
Parent
Re:This is meaningless (Score:2)
At the very least, I'd expect any file system Apple would consider suitable for switching to to support arbitrary metadata. A server based system like Solaris may not need it so much, but a desktop system that associates icons, file types, and miscellaneous information useful in searching, really should use a file system that supports arbitrary metad
Re:This is meaningless (Score:2)
What about the various BSDs?
Re:Tiger Filesystems (10.4.6) (Score:3, Funny)
For the record, if I had mod points I would have modded GP up as "Informative"
Last login: Thu Apr 20 18:20:18 on ttyp1
Welcome to Darwin!
[athena:~] aibrahim% ls -l
total 8
drwxr-xr-x 9 root wheel 306 Apr 4 11:14 AppleShare
drwxr-xr-x 7 root wheel 238 Apr 2 2005 URLMount
lrwxr-xr-x 1 root wheel 49 Nov
What Apple Is Looking For (Score:5, Interesting)
Re:one word (Score:2, Interesting)
Who stil uses HFS+ anyway? (Score:2)
And from the view point of a average user, he wont see a difference regardless of what FS hes using..
Re:Who stil uses HFS+ anyway? (Score:2)
Intel Macs good oppurtunity to make a clean break (Score:3, Informative)
So now with the Intel Macs and no need for Mac OS 9 support, Apple can tell all their developers that all Universal apps must be able to run on UFS. That way should Apple decide to adopt ZFS it should be a painless transition. Holding on to HFS + with the Intel Macs for this long will hamper any transition into a future filesystem. This will prepare Adobe and Microsoft to write their new Universal versions to be able to accept any type of filesystem and not rely on the resource fork of HFS
That's my 2 cents.
that's nice. now fix network file systems. (Score:5, Insightful)
I've looked at AFP, but that essentially mounts the remote system as if it were an external drive, and assigns everything to the logged in user, so ownership, permissions, etc., are all really screwy. Plus that gets even worse if you use fast user switching -- now two people are independently trying to mount the same network drive, each claiming to own it outright. And it doesn't look as seamless as, say, simply going to
SMB isn't much better.
There's always AFS, but that's so bloody complicated that I'd take a lot of convincing before I seriously considered it.
This isn't even to mention the problems that most apps have in working in a networked environment -- applications simply aren't designed for, say, networked home directories, and *especially* aren't designed to be running simultaneously on multiple systems. So if I've got Mail.app running in the den and I log in upstairs to check mail just before I go to bed, things could get messed up.
I'm not sure there's even been a new network file system since the mid 90's, has there? Certainly, nothing with broad support that fixes some of these issues? All I want is UNIX filesystem features -- simple locking (I guess), owners, regular permissions. Doesn't even need to do ACLs. Transparently mounted so it looks like it's part of the local filesystem. And at least reasonably tolerant of network glitches, so a momentary drop at the server (or whatever else happens to screw NFS connections to the wall) doesn't put all apps which have even heard of the mount point into an uninterruptible kernel-level deep-freeze (what's the point of kill -9, dammit?). Is that so difficult?
Most excellent! (Score:3, Insightful)
HFS is big endian (Score:4, Insightful)
Even so, all of the other features of ZFS are worth much more than this. If Apple is anything more than a consumer widget company now, ZFS should definitely be under consideration.
ZFS is far from "just another filesystem," and comparing it to existing filesystems indicates a lack of understanding. Take a look at this presentation [opensolaris.org] for more information.
Re:HFS is big endian (Score:5, Informative)
Currently on intel macs, all disk IO has to be byte swapped, degrading performance. ZFS on the other hand will store data in the machines native format.
While the non-native byte ordering does slow performance this only applies to metadata and not the contents of the files.
Parent
rewriting the Finder (Score:4, Informative)
Apple should just buy SUN (Score:5, Interesting)
Mac OS X is a great consumer OS, but performance at the high end is sub-par. For servers, Solaris is fast and scalable, has nifty features like ZFS and DTrace, but the UI is pretty crude. Imagine a merger of these. Looking at their market [yahoo.com] caps [yahoo.com], Apple can afford it.
Re:Apple should just buy SUN (Score:5, Interesting)
I like your comment. And the reason why I like it so much has to do with my (past) experience on a University system. Universities developed servers and file sharing with Macs using Sun's servers because Apple really didn't have a server. I mean you could put a Mac (usually an older one) on a network and tell it to share files with everyone but it lacked lots of stuff you would expect to have in a server and it tended to be pretty slow.
I would argue that it was the University exposure that lead Apple to offer Ethernet on Macs. Appletalk was great and people hooked themselves up very quickly with Appletalk (you could buy cabling at your local Radio Shack or use almost any twisted-pair cabling, including electrical cables) but Ethernet was a lot faster and more reliable. I'll bet the folks who developed 10 Base-T Ethernet were thinking Appletalk when they came up with the design for the connector and the twisted pair.
But I digress...
I did a fair amount of work with a hard Science department and they all had Suns as servers. They were strictly Sun Unix for the geeks and they developed systems and applications on that model. But for those who actually had to function in an office environment, the Macs were standard. They used Microsoft's Office for memos, reports and spreadsheets and TeX for document publishing. Everything you did worked.
Frankly, I think this legacy is part of the reason why Apple got fascinated with Unix again (that, and Jobs' NeXt company). It would be a good marriage. Apple's X-Serve RAIDs with Sun. Sweet!
Parent
unfounded opinions (Score:3, Funny)
Re:HFS+ vs. UFS vs. ZFS (Score:2)
Re:HFS+ vs. UFS vs. ZFS (Score:4, Informative)
Parent
Re:HFS+ vs. UFS vs. ZFS (Score:3, Informative)
It helps to have knowledgeable moderators, but posts still have to be moderated to be useful for a general audience. In this case, the post in question doesn't tell you much if you don't happen to be very familiar with different file systems for OSX and the compatibility of OSX software with those file systems.
Is the grandparent post flamebait? maybe not. Without minus_273's though, its probably not useful enought to be modded up either. Whether the moderation system is right or wrong, isn't the point here
Re:dunno bout m$... (Score:3, Insightful)
Demonstrably not true. I've thought that way since I learned to read. In fact, I was confused the first time I dealt with an MS-DOS machine (before I ever heard of Unix), because the instructions showed commands in upper case and I thought I had to type them that way. Everything I do is based on identifying and classifying differences - "F" and "f" are patently not the same thing to me.
People, at least people familiar with
Re:HFS+ vs. UFS vs. ZFS (Score:5, Informative)
It's the same deal with the problem with Classic. All 3 items you link to are for OSX 10.0 and have been fixed since then. The number of UFS problems now is minute compared to then.
Parent
Re:YAY! (Score:2)
Re:BSD leads, Apple follows once again (Score:2, Insightful)
Re:What ever happened to BeFS? (Score:3, Informative)
Re:Reiser4 would be a better choice (Score:4, Informative)
Parent