Apple Looking at ZFS For Mac OS X

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

Comments

Comparison of Filesystems.

[Whiney Mac Fanboy]

Have a look at wikipedia's Comparison of file systems page to see the difference between ZFS & HFS+.

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.

[Metabolife]

Also note that ZFS doesn't have a file change log. That could come in handy if/when apple viruses start coming around.

Re:Comparison of Filesystems.

[lokedhs]

I think the major advantage is the fast snapshotting and cloning. It uses copy-on-write so that it doesn't take more space than what you actually change.

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

Re:Comparison of Filesystems.

[iamdrscience]

I mean who's really going to need a 16,000,000 Gigabyte file

A post from slashdot in the year 2030:

Sure, it may seem to be overkill but remember when Whiney Mac Fanboy said "16,000,000GB should be enough for anyone"?

Re:Comparison of Filesystems.

[Jeff DeMaagd]

Journaling beyond metadata? Wouldn't that aid file recovery if the writing software screws up a write?

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.

[KingArthur10]

I remember the early nineties when I said "I'll never fill this 40 MB hard drive!" Oh how times have changed. Someday, we may just need 16,000,000 Gigabyte files. I don't know when, I don't know why or how, but it might happen. Especially the scientific and content producing communities (which OSX targets fairly heavily). Space is never enough no matter who absurdly large it may seem today.

Re:Comparison of Filesystems.

[captnitro]

Since OS X.3, I believe the kernel has defragmented files under 20 MB on the fly.

Re:Comparison of Filesystems.

[croddy]

Also -- hard links. One would be hard pressed to find a filesystem with poorer hard link support than HFS+, except those that don't support links at all.

Re:Comparison of Filesystems.

[Fweeky]

Well, that and all the other neat things ZFS does, like pooled storage making adding/upgrading disks easier, dynamic striping/redundancy, cheap optionally writable snapshots, bombproof data integrity, write performance similar to log structured filesystems, very clever IO scheduling, etc.

ZFS would make MacOS X a more attractive server platform, especially with kliky intuitive admin tools; cue SOHO XServe RAID tower system for mass file storage with redundancy, reliability and expandability with wide geek appeal and more usability than OpenSolaris for a start.

Re:Comparison of Filesystems.

[ylon]

With the number of hard drive failures that I've seen in our region recently (being that I am part of a group of consultants that works across the region and we've seen well over 100 hard drives fail within the last 3 months with bad sectors and such, seems very odd, but something is up as it ranges in brands and from home consumers to very beefy servers) I would say that ZFS is a huge benefit for anything ranging from laptops to servers. I would love to have continual failure monitoring for bad blocks and such. I am extremely excited about this as it will also allow the pooling of storage space across my personal office. Also, does it function similarly to the Google FS or other global filesystems that help to create redundancy across the pool? That would be exceptionally valuable. I thought that I'd read about ZFS actually functioning as a disconnectable file system as well that could "sync up" when reconnected to the network, but perhaps that is from some of my other filesystem exploration.

Re:Comparison of Filesystems.

[Gentlewhisper]

Windows Vista or MacOS X.. which will you choose?

Re:Comparison of Filesystems.

[aaron.rowe]

An Exabyte (EiB Exbibyte) is 2^60 or 1152921504606846976 bytes
A Gigabyte (GiB Gibibyte) is 2^30 or 1073741824 bytes.

So 16 EiB = 17,179,869,184 GiB not 16,000,000.

that small error is 17,163,869,184 GiB of extra space!

Re:Comparison of Filesystems.

[clifyt]

"HFS+ is subject to fragmentation (but Apple, like MS, provides no tools to help you deal with it)"

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' :-)

Re:Comparison of Filesystems.

[Gilmoure]

Heh, I remember the early '90s when I said (after discovering Giffy Girls), this 230MB hard drive is not enough. Need LaCie Joule hot swap drive tower.

Re:Comparison of Filesystems.

[Lucractius]

how bout NTFS... they bury hard links under such arcane obfuscations and warnings that despite a huge benift they would give me... i simply cannot fathom why i should risk my data, and my entire os setup stability to use them.

Re:Comparison of Filesystems.

[dorkygeek]

Ever heard of MTBF? If your sample is large enough, you will see lots of hard drives fail within short periods of time.

Re:Comparison of Filesystems.

[foniksonik]

As a part time graphics guy, this feature would make life much better.... I periodically have to save very large files after having made the smallest of changes... a typo for example... and yet saving the document takes as long as if I had made a full copy of the file.

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, available for review.

Implementing this functionality at a FS level will make it practical whereas now you have to rely on a program like Photoshop to create a 'scratch disk' that takes up huge amounts of RAM and physical space, making for an overall unwieldy document memory footprint the application has to traverse and manipulate as you make changes.

If they do this and can provide Application level hooks that are easy to implement, it will put OS X back on top for large file manipulation application developers like Adobe... simply because the performance benefits will showcase their applications so much better than the alternatives.

Re:Comparison of Filesystems.

[Whiney Mac Fanboy]

That's an interesting post - thanks for that.

I'm interested in you claim that an OS X engineer said not to fill your disk beyond 60-70% for the system to work best. Can you provide any backup links for that?

Re:Comparison of Filesystems.

[Blakey Rat]

Microsoft provides a defrag utility in Windows XP, and Windows 2000, and 98, and 95. I don't know about Vista, but try your best to not spread FUD, huh?

Re:Comparison of Filesystems.

[shawnce]

Might want to review the following to better understand fragmentation and how HFS+ suffered and fights the issue...
HFS plus fragmentation

Also XFS doesn't use journalling, it is a transactional file system that ensures on disk structures are always consistent, no need for a journal.

Re:Comparison of Filesystems.

[Koumaros]

I'd like to see the reference about only filling drive to 60-70% max, I have servers running lots of archive logs that need to be cleaned off every month, seems like they slow down a lot right before cleanoff.

Re:Comparison of Filesystems.

[araemo]

Go try and defrag a windows drive with less than 20% free, it'll give you a warning. :)

Most modern filesystems do some amount of 'defrag' automatically over time. Windows XP w/ NTFS does this, I would bet HFS+ is designed to do this. Of course, if there isn't a lot of free space to play with, the automatic 'opportunistic' defrag has a lot less chance of moving a large file to a bit of contiguous free space. If you can manage it, don't fill your drives to the brim. It will hamper performance, and it will make defrags take MUCH longer if you seriously fragment your files.

The way I understand it, sometimes when you overwrite a file, instead of reusing the same blocks, the FS marks those as free and writes to some currently free blocks, 'defragging' that file.

Re:Comparison of Filesystems.

[BrokenHalo]

Hmmm. Curious survey results there. Although I don't fall into those categories (my next computer will be built by myself, and it will run Linux as usual) I'm not entirely surprised by a preference for Mac. But the difference there is so big, the immediate suspicion that comes to my mind is that someone has been stacking votes...

Re:Comparison of Filesystems.

[BrokenHalo]

I seem to recall that Apple give you a choice of filesystems at install time, one of which they describe as a "Unix filesystem" (presumably UFS). IIRC that supports hard linking, if you like that.

Re:Comparison of Filesystems.

[Azarael]

I'm no expert, but it seems like the disk head would have to seek a lot further to move between free sectors since there aren't lots of big chunks of free space lying around.

Re:Comparison of Filesystems.

[BrokenHalo]

I'd like to see the reference about only filling drive to 60-70% max

It might not even be written down any more. Back in the day (here I'm talking about 20 years+ ago) in the mini and mainframe world, this was pretty much a truism that everybody just knew, and many of us sysadmins had to spend quite a lot of time juggling drive usage in order to get the best access rates.

I still try to maintain that amount uf usage on any machine I want to behave sweetly, although I haven't done any formally quantified benchmarks on this for some time.

Re:Comparison of Filesystems.

[BrokenHalo]

Microsoft provides a defrag utility in Windows XP, and Windows 2000, and 98, and 95.

FUD aside, they did this because they pretty much had to. The FAT16 and FAT32 filesystems were (are), not to put too fine a point on it, a godawful piece of crap that desparately needed regular defragging to remain functional. If they're using the same filesystem in Vista, the need won't go away.

Re:Comparison of Filesystems.

[clifyt]

This was actually addressed.

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

Re:Comparison of Filesystems.

[TheNetAvenger]

HFS+ is subject to fragmentation [themacintoshguy.com] (but Apple, like MS, provides no tools to help you deal with it)


Ok, both companies deal with in their own way. Apple has on the fly for small and critical files.

And MS, WTF are you talking about, NTFS is 'less prone' to fragmentation than many file systems, but with that aside, MS had provided defragging tools in the OS for 10 years now. Windows also defrags in the background, and especially critical files that change like the profiles, pagefile, hive, etc.

So how does Apple and MS NOT deal with defragging again? Do you even use either OS?

Re:Comparison of Filesystems.

[drinkypoo]

However, you can also defrag NTFS partitions, and have it make a positive difference, too. Microsoft's defragger differs from others (at least when XP came out) in that it respects the locations into which XP has relocated blocks of files needed at startup for boot time improvement.

Re:Comparison of Filesystems.

[SchrodingersRoot]

by default, the NT line (including XP) uses NTFS. I mean, one of my XP computers still has an old drive with FAT-32 on it, but that's 'cause I'm lazy. And Vista is ostensibly using an Transactional NTFS
so....yeah.

Re:Comparison of Filesystems.

[Fred_A]

In a few years :

30 gigs High definition feature movie
150 000 000 gigs embedded obsucation, multiplatform crypto code, keys, etc.
------------
150 000 030 gigs file.

Re:Comparison of Filesystems.

[Blakey Rat]

1) Nobody's used Fat32 in ages, except for things like portable hard drives and USB memory sticks, and then only because the three major OSes can't agree on a single read/write filesystem that can sanely support more than 80GB or so. (XP can't read/write HFS+ or EXT, OS X and Linux can't write NTFS. Pain. In. Ass.)

2) Don't just gloss over the fact that the original post made a blatant lie about Windows. I hate when this community will jump the gun to declare Microsoft evil no matter what they're doing, but when someone makes up crap to make Windows look worse there's no response at all.

Re:Comparison of Filesystems.

[mattwarden]

I mean who's really going to need a 16,000,000 Gigabyte file

Actually, I keep an archive of all Slashdot dupes...

Re:Comparison of Filesystems.

[georgewilliamherbert]

There were enough of WAFL's methods and algorithms published in 1996 to reimpliment to those specifications in a cleanroom. WAFL really isn't all that complicated.

That's no more of a copyright violation than Linus coding Linux to the SysV Interface Definition.

Re:Comparison of Filesystems.

[dfghjk]

Drives don't have independent read/write heads. They have a single actuator that can process only one I/O at a time. You can queue commands into them and get optimizations that way, but heads can't be used independently.

It's discomforting to know that engineers recommend that you not use 1/3 of your storage so that the OS doesn't have to work so hard. That employee needs to be fired.

I would tend to agree with the BS theory.

Re:Comparison of Filesystems.

[dfghjk]

40MB? You must be thinking of 1986. by the early 90's all drives were much bigger than that.

Re:Comparison of Filesystems.

[KingArthur10]

lmao. Yeah, you're right. THanks. I was thinking of my old 1980something packard bell (8mhz, 1MB RAM, 40MB hard drive). lol. The one I got in 1993 was a gateway (33Mhz, 4MB RAM, and a 120MB hard drive).

Re:Comparison of Filesystems.

[Kjella]

Look up any decent hard disk review site and compare sequential read vs random reads, and you'll see that it suffers quite badly. As for the operating system handling that, I don't know about OS X but Windows certainly doesn't. The "never fill it past 60 or 70%" is simply because than the OS can pick large open chunks, avoiding fragmentation but it does nothing to fix fragmentation. Once your drive has been close to 100%, the last files will be in a zillion fragments all over the disk. They will sit around like little road bumps making sure all other files will be fragmented too.

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.

Re:Comparison of Filesystems.

[larry bagina]

UFS doesn't have native support for resource forks (they fake it with hidden folders, like with MS FAT disks).

Re:Comparison of Filesystems.

[mikefe]

Journaling beyond metadata? Wouldn't that aid file recovery if the writing software screws up a write?

Not if the last write operation was truncate (which sets the file size to zero just before writing the contents of the file over again)

The fact is that most apps write the entire contents of their files on every save, and it is a multi-step process. truncate, write 4k, write 4k, etc.

You'd need transaction support like what reiser4 offers. But your apps would still need to use the API.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Great if it's true

[the_humeister]

But why just ZFS? Why not add JFS or XFS as well? Hell, why not add in ext3 while they're at it? Speaking of which, does anyone have Mac OS X running with a native non-HFS, non-UFS filesystem?

Re:Great if it's true

[CastrTroy]

I wonder the same thing with windows. There are only 2 file systems. FAT32 and NTFS. I don't think this is a good idea. There is no one filesystem that works best in all cases. That's what's nice about Linux. There's like 10 different file systems to choose from. Maybe most people leave it at whatever the default is. But that doesn't matter. For those who care to research enough, and find out which filesystem is the best for their system, they will be able tos see the advantages. The other nice thing is being able to use different file systems for each partition. Like an encrypted one for your home partition, and a stable fast one for your system files.

Re:Great if it's true

[Fweeky]

"But why just ZFS? Why not add JFS or XFS as well? Hell, why not add in ext3 while they're at it?"

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 bunker as well? Why not add in a bridge while you're at it?"

Might be nice to have them all, and they certainly share certain requirements, but trying to build them all at once isn't necessarily a good idea when all most people want is a nice place to keep things.

Re:Great if it's true

[flooey]

Maybe most people leave it at whatever the default is. But that doesn't matter.

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

[Nugget]

Yeah, because the last thing I want to do is use the stable filesystem for my home partition.

Re:Great if it's true

[CastrTroy]

I could understand if you were a little niche company, only selling your OS to a specific market (Maybe QNX?) then having an OS that only supported 1 or 2 file systesm wouldn't be a bad idea. However, when you're Microsoft, and you market your OS for Home Desktops, Workstations, File Servers, Database Servers, and just about everything else under the sun, it starts to make more sense to allow people to use different file systems. No one file system is going to make all the users happy.

Re:Great if it's true

[moof1138]

Unlike Open Source projects Apple has to do a lot of regression testing and QA, and already isn't perfect there. I imagine they take a lot of time already. Imagine having to run all those tests on five or so filesystems not only for all the OS bits, but for all their other software projects.

Also imagine Disk Utility having a popup to format a Disk that made users choose between:

EXT3
FAT
HFS+
HFS+ (case sensitive)
JFS
UFS
XFS
ZFS

Then try to explain to Grandma which is the correct one for them to choose in a litle help blurb.

Sometimes Apple has to make choices as to which is the best approach which limit things that might annoy power users, but make things simpler for everyone else. If Apple took the Linux approach, OS X would run on every piece of hardware out there, would have three or four window managers, five filesystems, fourty text editors, and would be hated by typical users for the brief time Apple was around before they went out of business.

Re:Great if it's true

[c_forq]

But then the people making software will have to support those file systems too. Can you imagine the anger and confusion that will take place when Joe Smith can't get "Sponge Bob SquarePant's Magical Sea Adventure" to work for his son, because his hard drive is the wrong file system? And how are new companies supposed to get a foothold in the market if they already have to make 5 different versions from the start?

Re:Great if it's true

[greed]

Also imagine Disk Utility having a popup to format a Disk that made users choose between:

Don't confuse possibilities with defaults. There's two mechanisms already established for giving advanced users more choices: Option-click a control or menu item to get more choices. Or a show-advanced-options preference without a GUI interface that you can turn on with the "defaults write" command.

Plus the whole "Advanced Options" kind of button....

Re:Great if it's true

[amliebsch]

They do "allow" you to use other file systems - nothing stops you from installing a third-party driver for ext3, for example - but they don't develop them and don't support them, which seems reasonable, because they have no control over their development.

Re:Great if it's true

[forkazoo]

But then the people making software will have to support those file systems too. Can you imagine the anger and confusion that will take place when Joe Smith can't get "Sponge Bob SquarePant's Magical Sea Adventure" to work for his son, because his hard drive is the wrong file system? And how are new companies supposed to get a foothold in the market if they already have to make 5 different versions from the start?

Sure, there are occasional quirks, such as if a file system is case insensitive, but the program needs to install "Fun.exe" and "fUN.exe". But, how would this mandate needing multiple versions of the program for each file system. The app just uses fopen() and fread() or whatever equivalents. The only software that would ever touch the disk at a level that it would even be aware of the file system would be disk utilities like defraggers and file system checkers. In UNIX and similar OS's, it's not at all unusual to have half a dozen file systems mounted as part of the same hierarchy. In general, the user never notices if / is ext3 and /storage is XFS on LVM, and /usr is ZFS on a RAID array...

Re:Great if it's true

[swimmar132]

How does user-level software depend on the type of filesystem used at all?

Re:Great if it's true

[fm6]

You seem to think the primary purpose of software is to be used. Wrong! The primary purpose of software is to be played with.

Re:Great if it's true

[BrainInAJar]

That just seems some pretty bad FUD to me. All it takes is for the developer to assume case-ambiguity (only refer to files with proper case, but don't name 2 files with only case differences), and speak straight to the kernel/os API. No posix program seems to have any trouble dealing with ZFS, ext3, ricerfs, xfs, etc. because they're all case sensitive and that's really the only meaningful difference from the developer standpoint (with the exception of extended attributes, which aren't common enough to matter, but can be dealt with in the same way as the case problems)

Re:Great if it's true

[Vancorps]

Ever applied ACLs to applications? Ever worked with metadata in files? All of the filesystems would store the information differently. Do you see the overhead problem now?

You'd have to create a seperate db to keep track of all the info and let the db handle all the writes to the file system. Sounds like a huge pain to me. I'm sure there are more elegant ways to do it but there are definitely dependencies especially in a file server world. or a properly secured workstation.

Re:HFS+ vs. UFS vs. ZFS

[minus_273]

ufs does not work with all software especially stupid applications made by microsoft

Slashdot is Getting Better Again

[LakeSolon]

A story that consists of a link to wikipedia and a mailing list posting about an OS possibly (maybe, potentially) switching filesystems.

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.

Re:Slashdot is Getting Better Again

[Ilgaz]

We are bugged because of different reasons. Before I have seen your comment, I was about to flamebait about this:

"Is this a glimpse of hope for all those of us who think HFS+ isn't up to par for a 21st century OS?"

Who are them? I really want to meet with them as a guy using disk filesystems since 1984. 21th century OS?!

Please editors, apple.slashdot.org has started very slow but it is very widely read by Mac users now. You don't need that "thing" you know? I don't think it needs more explanation than that.

This is meaningless

[squiggleslash]

Here's a listing of the file systems currently supported on OS X Panther (it may be more for Tiger, I don't know):

$ ls -l /System/Library/Filesystems/
total 0
drwxr-xr-x 8 root wheel 272 14 Mar 12:46 AppleShare
drwxr-xr-x 7 root wheel 238 12 Apr 2005 URLMount
drwxr-xr-x 6 root wheel 204 14 Mar 12:47 cd9660.fs
drwxr-xr-x 3 root wheel 102 22 Dec 2004 cddafs.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:48 ftp.fs
drwxr-xr-x 5 root wheel 170 14 Mar 12:47 hfs.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:47 msdos.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:47 ntfs.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:47 udf.fs
drwxr-xr-x 4 root wheel 136 14 Mar 12:46 ufs.fs
$

HFS and UFS are the official choices of file system for installing your bootable OS X or Darwin system. The rest are either network based file systems or are specific choices for interoperability with other operating systems.

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

[Anonymous Coward]

ZFS actually is a ver good file system.

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

Re:This is meaningless

[jb.hl.com]

Solaris and GNU/Linux are the two most popular Intel platforms save for Mac OS X and Windows.

What about the various BSDs?

Re:This is meaningless

[squiggleslash]

It's probably very good in the performance arena, but for some reason, it still appears to live in the 1970s in terms of what it stores - ie named flat files.

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 metadata in 2006. This is the direction Apple's going in, and I can't see them adopting wholesale a file system like ZFS without making a lot of changes.

Re:This is meaningless

[Ilgaz]

I only have these lines different on (stock) Tiger 10.4.6

"drwxr-xr-x 4 root wheel 136 Aug 23 2005 webdav.fs"
"drwxr-xr-x 3 root wheel 102 Aug 23 2005 smbfs.fs"

Re:This is meaningless

[sommerfeld]

ZFS -- like solaris's UFS -- has support for something roughly equivalent to Mac file "forks" under the covers.
It also has a flexible & extensible on-disk format so that additional attributes/metadata can be added to files in newer versions of the filesystem without forcing existing pools to be reformatted.

Re:This is meaningless

[Pfhor]

From what I've seen, apple is actually moving away from "metadata in the file" to "metadata in the OS." I mean, spotlight keeps the index of everything, and apple is switching to a flat filesystem anyway. No more resource forks in their own apps (a .app is actually a folder of flat files called a package). OS X uses file extensions to determine icons first, if there is no metadata present, there are executable flags as in unix, etc.

I see spotlight as apple's attempt to get away from any one filesystem, it does the indexing and cataloging, in real time, to a seperate database.

Re:This is meaningless

[squiggleslash]

I'm not so bothered by forks, which are largely needed for backward compatibility with classic Mac OS, and which bundles do a good job of replicating anyway (in many senses, forks were a stand-in for one use of directories in the early days of the Mac, when the Mac file system didn't support directories.)

Arbitrary meta data though is relatively important, and I'm surprised it's taken this long for there even to be a standard BSD interface to the system. I would hope if Apple adopts ZFS (and I don't think there's any reason right now to suppose that's the plan, for the reasons I outlined earlier) it does add support. It would be a massive step back, in my opinion, to continue to remove something critical to good Desktop environments from modern desktop environments. Unfortunately, Apple's obsession of .DS_Store files and some of Avie's early memos on the subject do not give me that much hope.

Re:This is meaningless

[Just Some Guy]

What about the various BSDs?

Indeed. I would be absolutely amazed to find that there are more Solaris installations (which I've never actually seen in the wild) than FreeBSD (which I've seen at almost every Unix-based shop I've dealt with).

I don't have any hard numbers to back that up, but experience makes me pretty skeptical of that claim.

Re:This is meaningless

[BrokenHalo]

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+?

Err, how?

The only thing that has to access the filesystem directly is the kernel itself. For others to interoperate with the machine all they need is an appropriate abstraction layer such as NFS or Samba; they don't need to know anything about HFS+, ZFS or any of the other filesystems directly.

Re:This is meaningless

[CableModemSniper]

Just to counter your anecdotal evidence with my own, I've never seen any FreeBSD systems in the wild, but have seen Solaris at every Unix shop I've been to.

Re:HFS+ vs. UFS vs. ZFS

[Whiney Mac Fanboy]

Doesn't OS X already have UFS? ZFS is nicely buzzword compliant, but Mac users can migrate to a standard Unix filesystem today if they want to.

Yes, OS X allready has UFS, but according to Apple:

UFS is case-sensitive

With a UFS-formatted volume, you may have the two "My File" files in the same location as well as other similarly named files -- "My file," "MY file," "My FiLe," "my File," and so forth.

AirPort and UFS

AirPort does not function when Mac OS X is installed on a UFS formatted volume. For more information, please see article 106252: " Mac OS X 10.0: AirPort Does Not Work From UFS Partition "

Customizing Hard Disk Volume Name

You can permanently customize a hard disk volume name when using Mac OS Extended, but not (currently) when using a UFS-formatted hard disk volume. For more information, please see article 106191: " Mac OS X 10.0: Startup Volume Is Named '/' Instead of 'Mac OS X' "

Mac OS X Classic Environment and UFS

The Mac OS X Classic environment does not function the first time it is opened on a UFS formatted volume. For more information, please see article 106277: " Mac OS X 10.0: Classic Does Not Work From a UFS Disk On First Use "

Mac OS 9 and UFS

When you start up your computer using Mac OS 9.x, UFS hard disk volumes do not appear on the desktop and cannot be used.

(unfortunately, zfs would not fix many of these issues)

What Apple Is Looking For

[rpk]

There are probably two things that Apple would be looking for in ZFS: a shiny feature they can point to for their enterprise and video production markets, and for the consumer market, the promise of a simple, reliable way to back up and grow the storage of a Mac without have to worry about mounting/copying/moving volumes, managing backups, etc.

Who stil uses HFS+ anyway?

[nurb432]

Dont most of us now use UFS?

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?

[TheRaven64]

I don't think very many people at all use UFS on OS X. UFS is case sensitive. HFS+ can be case-insensitive but case preserving or case sensitive depending on the options specified to create the volume. UFS doesn't have journaling support, HFS+ does. UFS stores POSIX metadata. HFS+ stores arbitrary metadata. UFS files have single fork. HFS+ files have a data fork and an arbitrary number of other forks. UFS stores the meta-data in the associated file's root inode. HFS+ stores it in a central database which can be searched easily. All OS X apps works with HFS+. Most OS X apps work with UFS.

Oh, and HFS+ tends to benchmarks as being faster as well.

Re:Who stil uses HFS+ anyway?

[Ilgaz]

I hope you are joking. If you aren't joking, better donate to Fink project and OpenDarwin ports. Those will be only programs running happily under UFS.

If you are in Stanford and your particular program setup runs happily under UFS (or it needs it) it is not "we" or "us", "we" should be 90%+ of userbase if you want to generalize anything.

Oh /. , nevermind :)

Re:Who stil uses HFS+ anyway?

[LnxAddct]

Unless of course his filesystem does automatic versioning so that he can seamlessly go back to any version of a file at any time he wants to.
Regards,
Steve

Re:Who stil uses HFS+ anyway?

[RautenkranzMT]

Personally, I still prefer Case-enabled HFS+.

Re:Who stil uses HFS+ anyway?

[mattkinabrewmindspri]

I assume that the vast majority of OS X users still use HFS+, and it's what Apple recommends. I still use HFS+, because it supports useful metadata, like resource forks and type/creator codes.

Here's a (somewhat old) article describing why Apple recommends using HFS+(a.k.a. Mac OS Extended).

Re:one word

[rpk]

Yeah, it's pretty clear that for heavy-duty use, HFS+ is not really the way to go. With ZFS, Apple can build on what Sun has done, while at the same time they don't have to touch HFS+ at all, or fix all the it-doesn't-quite-work-like-HFS+ issues that UFS has. It makes a lot more sense for them to get ZFS to "just work" than to put that work into the existing UFS implementation.

Re:HFS+ vs. UFS vs. ZFS

[rsmith-mac]

From the AirPort page:

This issue is resolved in Mac OS X 10.1 and later.

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.

Re:YAY!

[Mr Pippin]

Hmmm, and why are "resource forks" a huge mistake?

Re:HFS+ vs. UFS vs. ZFS

[archen]

Yeah, as a Mac user I'd advise people to stay away from UFS on OSX. I figured that because it did so well on FreeBSD I'd use it on OSX as well. Using Jaguar I didn't have many problems and was okay with the system. Used UFS on my newer laptop with Tiger. Unfortuantly I was getting corruption problems. Reformatted the disk and tried it again 2 times but always had to repair stuff with fsck. So I went to case sensitive HFS+ with journaling. No more corruption problems and also noticably faster.

And as someone else said there are compatability problems with UFS and some applications. Mainly due to case sensitivity (would it kill MS to be consistent?)

Re:YAY!

[Anonymous Coward]

HFS+ supports multiple file forks (just like NTFS, except they are called streams under NTFS), but at the moment they are only used for Data and "Resource"

So yeah, Mac's still do have Data and Resource forks, nothing bad about them (OS X is less reliant on them though)

And if you ZIP a file, the Resource fork gets carried along, just with a . added to the beginning of the file name to hide it on UNIX systems, and the hidden attribute set on FAT32 drives (like USB thumbsticks) and such.

Re:BSD leads, Apple follows once again

[Anonymous Coward]

Obligatory: Why are you waiting on your ass for a feature in an OS for which you have all the code? Drive the development of ZFS on Linux yourself. Ask for help when you get lost, but don't just sit around wasting oxygen.

What ever happened to BeFS?

[Falcon040]

What ever happened to the Be Filesystem (BeFS)?

I read a few years ago people were doing a GPL'd open version for linux, but since that day have heard nothing...

Is it dead? The BeOS FS was supposed to be absolutely fabulous.

Re:What ever happened to BeFS?

[cjwl]

Isn't the guy who worked on the BeFS working at Apple now?

Re:What ever happened to BeFS?

[drewness]

Yes, Dominic Giampaolo works at Apple and is in charge of filesystems there.

Intel Macs good oppurtunity to make a clean break

[saha]

I very much wish for an updated filesystem for Mac OSX. I know that HFS plus (with journaling and meta-data searching where added later), I feel HFS + is showing signs of age. I was hoping when Apple first developed Mac OSX it had used the UFS system and then made a separate HFS+ partition for people who wanted to use a Mac OS9 on the PowerPC based Macs, but that didn't happen. Perhaps for the best at the time. Wilfredo Sánchez Vega wrote a whitepaper on the reasoning for HFS + at the time

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.

Re:dunno bout m$...

[Jay Maynard]

I disagree, rather strongly. Case sensitivity is the single greatest user interface botch in Unix. People just don't think that way until they've been conditioned to do so by Unix. (No, German and homonyms are not counterexamples; in neither case does the case of the characters involved provide sufficient context for disambiguation. To see why, consider what happens when the words are spoken.)

That some software breaks on case-sensitive filesystems is just one more reason to avoid them. Personally, I do find myself wondering how much work it'd take to make ZFS case-insensitive but case-preserving.

Why stop at ZFS?

[dnessl]

I read that Darwin has trouble scaling thread concurrency. Maybe Apple should just switch to Solaris, either licensed or OpenSolaris, and get ZFS with it. (Of course they would still run the MacOS personality and GUI environment on top of it.)

Re:Why stop at ZFS?

[Aram Fingal]

You mean switch to the Solaris Kernel?

I have heard all kinds of speculation about that since Ave Tevanian announced his departure. The Mach microkernel was his project.

Re:Why stop at ZFS?

[menace3society]

I heard that Solaris has problems with Mach IPC and peripheral plug-and-play. Why don't they license Mac OS X, or switch to Darwin, and get Mach IPC/P&P with it. Then they could run a shitty-ass Solaris/CDE personality layer on top of it.

Re:Why stop at ZFS?

[LWATCDR]

The real problem is Mach. Lots of unneeded overhead. I have a feeling that it will not go away anytime soon since it was Jobs stamp of approval from the NeXT days.
This isn't saying the microkernals are a bad choice. QNX and L5 both have good microkernals. Mach just has a lot of unneeded baggage.

Re:Why stop at ZFS?

[Halo1]

No release version of Mac OS X ever used a microkernel. The kernel uses mach code, but all of it (including the BSD personality) runs in one address space. It's just the logical compartmentalization that's still there. E.g. mach messages inside the kernel are plain function calls in OS X.

Re:Why stop at ZFS?

[LWATCDR]

Okay a none Micro-kernel Mach is just wierd.
I will take your word for it. That is just what I have read on some experts pages.
Live and learn.

Re:Why stop at ZFS?

[TheRaven64]

I have been saying for years that my ideal OS would be a Solaris kernel, a BSD userland and an Apple GUI. I wonder if finally people at Apple and Sun will start listening...

Re:Why stop at ZFS?

[Halo1]

Here's some things if you care to learn more about Mac OS X' kernel structure and the non-microkernel Mach: message 1, message 2.

Re:Why stop at ZFS?

[JulesLt]

If you're talking about the Ars benchmarking of OS X server, it definitely showed problems running standard Unix software (mySQL). However, Oracle state that they've achieved good performance on OS X server by modifying their software.

I've also seen the same idea suggested but with Linux rather than Solaris, for roughly similar reasons. I've even read suggestions they should port Aqua to run on X11!

Leaving aside the licensing issues of trying to build a proprietary layer on a non-BSD licence,
The usual error is to think that the OS X GUI environment is just something like KDE or Gnome, that can be stuck on front. The problem is that OS X is NOT a standard Unix architecture. Take a look at this diagram, and it shows the issue a little clearer. You don't have Aqua sat over X11 over Darwin over Mach. Darwin's sort of off to one size (explained on the next page), while the rest of the layers are - well closer to the old-school MacOS or Windows. In which case I'm not really sure what you'd get switching Darwin for Solaris.

http://developer.apple.com/documentation/Darwin/Co nceptual/KernelProgramming/index.html

Another factor to consider is that the main use of OS/X is as a desktop system while the main use of Solaris and most flavours of Unix is as a server-side operating system, typically supporting large volumes of concurrent requests (page requests, d/b queries, etc). I would wager that Apple have substantially modified Mach towards good Cocoa/Obj-C performance (which is heavily dependent on messaging) rather than the heavy threading optimisation that would be useful in a server OS.

Re:Why stop at ZFS?

[Billly Gates]

With OpenSolaris now ported and running excellent on the powerpc platform its a possibility.

However, Sun offered Apple this and jobs decided to use Mach and Next because it was what the engineers who came to Apple were familiar with and they didn't want to pay sun for the licensing costs and end up being dependent on them.

Apple learned their lesson with being dependent on Microsoft when the original mac was introduced where Jobs voided the non compete clause and windows was born. Very bad mistake.

But it would be nice to dream?

that's nice. now fix network file systems.

[dschuetz]

I just wish we could come up with a network file system that's worth the trouble. Right now, I'm using a Linux server with three Macs (two Tiger, one Panther), and everything is over NFS. Most of the time, it works fine, but if there's a weird hiccup, then the Mac will freeze solid and has to be hard power-cycled. Also, some apps simply won't run from a network share (or they'll run, but one thing or another won't be right). Install that app to a local drive, and it works fine. And this isn't even to mention security issues.

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 /Server/Shared or /Server/Apps.

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?

640K is enough

[Midnight Thunder]

The main advantage for HFS+ users (I mean who's really going to need a 16,000,000 Gigabyte file)

Wasn't 640K meant to be enough? That is to say, just because you can't imagine the need based on today's problems doesn't mean someone isn't going to find a need. I wonder how big a big database can get?

Re:640K is enough

[blugu64]

640k was supposed to be enough RAM.

Re:640K is enough

[BrokenHalo]

The first machine I worked on (a Burroughs B3700) had 128K of usable memory, and that was enough, then. OK, all the street lights in the area used to dim when we fired it up, but it was faster in some respects than the non-core-memory machine we replaced it with (a Honeywell DPS7).

Could make hard drives more reliable

[bblfish]

In my November 2005 I posted BlogEd, ZFS and OSX, where I described an odd software defect that occured to me on my 17" laptop, and that dissapeared after I reinstalled a new hard drive, after my old one died on me. I am not sure what the defect was due to, but it is clear that with ZFS hard drive corruptions would be detected much earlier. This would be quite a serious advantage.

Reiser4 would be a better choice

[Pegasus]

For what Apple is doing (desktop, multimedia) Reiser4 would be a much better choice. It offers most of the features ZFS does, is infinitely more feature-extensible and can be optimized for a specific task. ZFS on the other hand is more file-server oriented.

Re:Reiser4 would be a better choice

[alonso]

I think that you have to inform better, Raiser has journaling. From namesys site: "Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice"

Re:Reiser4 would be a better choice

[alonso]

Can you explain us why zfs is so mutch better than rfsV4 for a desktop use?

Re:Reiser4 would be a better choice

[be-fan]

Reiser4 is transaction-oriented, just like ZFS. The two actually use a similar principle (not journaling) to maintain consistency, based on COW'ing blocks in a tree, then committing the change atomically by swapping the pointer to the root of the tree in the parent node. Reiser4, however, instead of using the traditional block tree ZFS does, uses "dancing trees", which is kind of a B*-tree with ideas from log-structured filesystems mixed in.

Most excellent!

[csoto]

ZFS is one of the more interesting filesystem developments of late. While the address space is nice, it's the data replication features included that make this a potential candidate to threaten the proprietary (and expensive) DR features of modern SAN and NAS storage systems. Need a synchronous or asynchronous mirror? No problem. Just issue a ZFS command on your OSX/Solaris/Linux server...

ext2fs as an option

[Midnight Thunder]

With the help of the Mac OS X Ext2 Filesystem project ext2 is an option.

Re:ext2fs as an option

[Dlugar]

Unfortunately it's buggy (i.e. will most likely hose your ext2 partition after a while), and doesn't work properly on Tiger, the current version of OS X ("Read only support (for now) and be prepared for kernel panics and/or system hangs").

Why can't Apple include ext2 support standard?! It boggles my mind. There doesn't exist, today, a Unixy filesystem that both OS X and Linux can read and write to reliably.

Dlugar

Re:ext2fs as an option

[TheRaven64]

Here's a better question:

Why doesn't Linux support UFS? The filesystem was standard on UNIX platforms before Linux came along, and the code for handling it is BSD-licensed (at the very least they could make use of the inode structs, etc. from the header files). There are vendor-specific extensions, but they are fairly minor.

Well, it has read support, I suppose.

Re:Intel Macs good oppurtunity to make a clean bre

[littlerubberfeet]

Speaking of resource forks, I miss ResEdit. It was an awsome little program, and it did awsome things...

Re:HFS+ vs. UFS vs. ZFS

[cypherz]

"UFS is case-sensitive"
Why is this a problem? I've been living with case-sensitive systems for years. Never been a problem before.

"AirPort and UFS"
They bug you mentioned has been fixed, lo these many updates ago. Only affected 10.0.

"Customizing Hard Disk Volume Name"
OK, name it correctly when you format it. And live with the prepended "/". No big deal.

"Mac OS X Classic Environment and UFS"
People still use Classic? I haven't used the Classic environment since 10.0 shipped.

"Mac OS 9 and UFS"
People still use Classic?

Why are these problems?

HFS is big endian

[KonoWatakushi]

One of the reasons proposed over at Arstechnica has to do with byte ordering. 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.

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 for more information.

Re:HFS is big endian

[plasmacutter]

I agree that the endianness and byteswapping are an issue, though I think it may be 7-10 years premature to be considering such a switch based solely on that concern.

Considering the reads required for standard tree navigation, and the minimal number of instructions/cycles required to swap the bytes, It could easily wait until all apple machines within reason are intel a decade down the line.

that said, the finder is getting major revisions in leopard, or so the rumor sites say.

Re:HFS is big endian

[BurntNickel]

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.

Re:HFS is big endian

[Antony T Curtis]

Ever since the 80486 was launched, there was the BSWAP instruction (0x0f, 0xC8 | reg) which takes only 1 clock cycle to execute. It reverses the byte order of a 32-bit register. (also can be used in 16bit code as a hack way of doubling the number of available 16bit registers)

I cannot see how the byte order can be an expensive issue... Now, laziness is another matter alltogether!

Re:HFS is big endian

[Elwood P Dowd]

> If Apple is anything more than a consumer widget company now, ZFS should definitely be under consideration.

ZFS could bring new features and reliability to iPods.

So even if Apple is just a consumer widget company...

rewriting the Finder

[Aram Fingal]

I know this is just a little comment at the end of the story and not the main topic but the Finder really does need to be rewritten. It has a surprising lack of multithreading, even compared to Mac OS 9. This is most apparent (and most annoying) when you are navigating a slow network volume in the Finder. Quite often, you just can't do anything with but wait for the network to time out.

Re:rewriting the Finder

[sunderland56]

No, Finder needs to be renamed .

What the heck does it find? At least on Windows "Windows Explorer" gives you some hint as to what it does. Call it "Network Surfer", "Network Browser", whatever.

Yes, the Finder does have a "Find" menu choice, but so does most every app.

Re:rewriting the Finder

[Valdrax]

Thank you. I'm glad SOMEBODY else brought this up. The poor design of the Mac OS X Finder is one of several reasons that I honestly miss Mac OS 9. It just isn't as friendly to advanced users as the old Mac OS Finder was. While I don't hate it as much as the Dock, I still dislike it enough to pretty much do all file handling and application opening through the terminal.

The days of the desktop metaphor were brought to an end with Mac OS X. People deserve better from the company that was famous for and got it's strongest following for good GUI design.

Re:rewriting the Finder

[coso]

Aye, you're right there laddie. The Finder's networking issues are really annoying. Why do I need to wait a minute to get a "Disconnect" dialog for network share, dare I move out of range of my wireless without remembering to un mount the share... This is on a dual-processor macbook pro with 2gb of RAM. ZFS would be great, but how about getting the finder done right first.

Re:rewriting the Finder

[Dr. Sp0ng]

Call it "Network Surfer", "Network Browser", whatever.

Erm, network browsing is just a side feature of Finder. Its real job is file browsing. As much as it needs to be rewritten (I was actually complaining about this just last night), the name is fine. It's used, among other things, for "finding" files.

Re:rewriting the Finder

[NutscrapeSucks]

People have been complaining about this since the Mac came out in 1984 (it took ~10 years before the Finder actually had a "find" command).

Supposedly, the Finder is named after a camera's view finder.

Re:rewriting the Finder

[edalytical]

Apple is working on a new version of Finder. I'n not sure if it's a rewrite or just a update. Though the phrase "next generation versions of the Finder" in that job listing makes me believe it's a rewrite. Here's hoping for a rewrite.

Re:rewriting the Finder

[askegg]

The finder is multithreaded - try and copy two sets of files to differnet locations and you will see it works fine.

The problem is the network code in finder is blocking. The program must wait for a response before it can continue, which causes long waits for users - bad, bad, bad.

However, the finder does need a rewrite. Doing simple things like saving files to a specific location is difficult, this needs to be fixed. Copying files from one location to another requires juggling of multiple windows, this needs to be fixed. Hitting enter does not open the file/directory as expected - it goes to rename(?). You cannot cut and paste files/directories - huh? The list goes on....

Re:rewriting the Finder

[dankelley]

The finder is certainly a weak point about OSX. I seldom use it. To my mind, it's a lot easier to just use a terminal and type commands to move around, copy things, etc. Directory listings with "ls (pattern)" are easier than with the finder, unless you like scrolling up and down. Heck, you can get the double-clicking effect by the "open" command.

The worst thing about the finder is the inability to do a "create file here" operation. Why am I allowed to make a directory but not a file?

Really, what's the point of the finder? Does anyone with unix experience use it?

Re:that's nice. now fix network file systems.

[Midnight Thunder]

Have you filed a bug report with Apple? If you have reproducable cases then be sure to share them with Apple, so we can all benefit.

If you are a dev, you could see on the Darwin-Dev mailing list ( http://lists.apple.com/ ), or if not send feedback to Apple: http://www.apple.com/macosx/feedback/

Re:HFS+ vs. UFS vs. ZFS

[NutscrapeSucks]

Do MS Office and other major Mac apps run from UFS volumes now?

I stopped paying attention to UFS around 10,1, but at that point there was no support for the Mac Resource Fork, which was still widely being used.

Re:YAY!

[NutscrapeSucks]

The Mac File Code (eg "WDBN" instead of "DOC") is not stored in the resource fork -- it is in the file index. It's almost identical to MS-DOS extentions except there's no easy way to change them, and they get lost if you copy the file to a non-HFS system.

Re:HFS+ vs. UFS vs. ZFS

[Just Some Guy]

So I went to case sensitive HFS+ with journaling.

It never occurred to me to use a case-sensitive HFS+. What's the advantage of that?

IAAWTP

[NutscrapeSucks]

I'm just a home powerbook user, so I have very little need for ZFS or whatever, but I do need occassional SMB networking, and OS X really comes up short. Lots of hangs, freezes, kernel panics, wierd errors, and so on. CIFS==Crash-A-Mac. (Things are getting slowly better, with the keyword being slow.)

AFAICT, the "best" networking solution on MacOS X is to stick to ye olde AppleShare (eg Win2K Server running SFM). However that's too cumbersome for most home networks.

Re:IAAWTP

[Scudsucker]

What kind of network are you running samba on? My Macs can connect via samba to both my linux and 2k boxes just fine over my lan, and I've connected just fine over campus networks. It just gets bitchy when the server disconnects, which usually happens when the Mac goes into sleep mode.

Re:IAAWTP

[NutscrapeSucks]

I think it's related to funky wireless (802.11b), although I've had problems on ethernet as well. And yes, a lot of the problems seem to be related to sleep. I've learned to connect/copy/disconnect and that seems to work OK -- any sort of persistant SMB connection and it's likely the Mac will go south sooner or later.

Re:HFS+ vs. UFS vs. ZFS

[archen]

For 99% of people, probably nothing aside from the same headaches as MS not supporting UFS ;) I've also been known to use pkgsrc for software distribution on my mac and that requires a case sensitive file system for some reason. Mainly I just wanted something as close to a Unix file system as I could get so it was a pretty good comprimise.

Re:HFS+ vs. UFS vs. ZFS

[Whiney Mac Fanboy]

Hmmmmn, you're quite right - it's been some time since I tried UFS, however, as Apple has fixed the problems I originally noted, they've also introduced new problems

(and as others in this thread have noticed, it doesn't play well with legacy apps)

Think you'll get it?

[Just Some Guy]

I think the major advantage is the fast snapshotting and cloning.

FreeBSD's UFS supports snapshotting, but Apple didn't port that feature over. I'm not sure why they'd fully support ZFS when they're not fully supporting the other filesystem they already have.

I've made a few "what about UFS?" comments in this story, but I hope I don't come across as some weird filesystem fanboy. It's just that I can't figure out why this announcement is so exciting. ZFS is cool, sure, but I see it as an incremental improvement to widely used Unix filesystems rather than a quantum leap.

Re:Think you'll get it?

[lokedhs]

I think it's a quantum leap. Not because of the snapshotting or error checking, but the thing that really makes ZFS a completely different beast is that it is (to my knowledge) the first file system (or should I say "storage technology"?) that actually joins two traditionally separate concepts: file systems and volume management.

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.

If you don't consider ZFS a quantum leap in file system technology, I wonder what it would take for you to use that expression (set aside for the moment the people who argue that "wuantum leap" should in fact mean the opposite :-) ).

Re:Think you'll get it?

[vought]

I've made a few "what about UFS?" comments in this story, but I hope I don't come across as some weird filesystem fanboy. It's just that I can't figure out why this announcement is so exciting. ZFS is cool, sure, but I see it as an incremental improvement to widely used Unix filesystems rather than a quantum leap.

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 other words, we expect Apple to adhere to the 1980s and 1990s playbook of "NIH" - in other words, if Apple didn't come up with it, it's crap.

I think Steve Jobs changed all that, but I think there are lots of us who still find it interesting when Apple drops some in-house technology (Intel chipset over Apple's ASICs, Mach over NuKernel, KHTML over ????, etc.) for free software or technology for equal or better alternatives. We spent years wishing they'd do it, and now they are.

If the rumor is true, someone somewhere got ZFS working already, made a cool demo of a feature, showed it someone who showed it to Jobs, and now it's a real, honest-to-God feature.

Re:Think you'll get it?

[TheRaven64]

but the thing that really makes ZFS a completely different beast is that it is (to my knowledge) the first file system (or should I say "storage technology"?) that actually joins two traditionally separate concepts: file systems and volume management.

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.

Re:Think you'll get it?

[booch]

I agree that there was a lot in VMS that the world has "lost". I think that modern UNIX implementations should look at what VMS had, to reuse some of the good ideas that we still have not replicated. My favorite is the security system -- various small capabilities that each user (or program) could be granted. And the super-user only had one capability by default: the ability to grant privileges. I also appreciated the automated versioning, with the ability to pull up a previous version from the filesystem without having to use any special programs.

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.

Re:Think you'll get it?

[danbeck]

Whine, whine.

"Nobody pays attention to us!"

Sorry BSD folks, maybe if you whined lounder, we might finally recognize your collective brilliance.

Re:Think you'll get it?

[Just Some Guy]

Sorry BSD folks, maybe if you whined lounder, we might finally recognize your collective brilliance.

I guess it worked.

Re:Think you'll get it?

[killjoe]

I suppose Compaq owns VMS now due to their purchase of Digital. They are probably milking the "legacy" customers like CA does and they will milk them for years. It would be nice if they open sourced it though. I mean if Sun can open source solaris compaq can open source VMS.

Re:Think you'll get it?

[booch]

HP owns it now, since they bought Compaq shortly after Compaq bought DEC. I don't see any reason they couldn't Open Source it. It's old enough that I'm sure they own almost all the copyrights to the code, and any patents would have expired by now. I can't image much 3rd-party code being used at that point in history anyway. Perhaps some add-on type software, such as the RDBMS, but not the core.

Re:Think you'll get it?

[Heraclius]

The RDBMS used with VMS was Rdb, which already has been owned by Oracle for years (not Dec/Compaq/HP).

Re:Think you'll get it?

[TractorBarry]

And don't forget VME (Virtual Machine Environment) with it's concept of file generations whereby each time you change a file a new version of the file is created which differs only in it's generation number. The original file is also still there until you explicitly delete it (or use the "DELETE_FILE_GENERATIONS" cxommand to delete multiple old generations at once)

e.g. If you create a file called "Fred" by default it gets a generation number of 1 and you can refer to it either as "Fred" or "Fred(1)". Now when you edit this file the resulting output is saved as "Fred(2)". So now you can call "OPEN_FILE(Fred)" and you'll open "Fred(2)". However call "OPEN_FILE(Fred(1))" and you open "Fred(1)". Any amendments made to the file always result in a new generation of the file being created with a generation umber of "previous highest + 1".

Files can also be held in something akin to a directory called libraries and, you guessed it, these can have version numbers too (there are alos "Groups" which function more like directories as they don;t have generations)

Having worked with the VME file system for a number of years I'm afraid I found all the Windows/*NIX file systems terribly, terribly primitive. "What ? Only one generation of a file at any one time ? What happens if you wan't to recover from 10 edits ago ?"

Makes source code version control a breeeze too.

Re:Think you'll get it?

[gig]

>[ZFS] joins two traditionally separate concepts: file systems and
> volume management.

Mac OS X disk images are whole volumes stored as single files. You open one and it mounts just like attaching an external hard drive. They can also be AES-128 encrypted, or data-compressed, or both. They can be HFS+, UFS, FAT, or a DVD or CD master. They can be writable or read-only. The icon looks like a document with a hard disk stored in it, or a "virtual hard disk."

It's not done the same way as ZFS, but in practice I have hundreds and hundreds of volumes stored in one HFS+ partition. Only some are mounted at any one time, but when they are they are full-fledged volumes like any other. I can mount all of them if I want.

All you have to do to create a disk image is drop a folder on Disk Utility. Boom. It's as fast or faster than creating a zip file, but has the advantage of including hidden files, metadata, icon resources, and other stuff that gets skipped by many backup or archiving utilities.

> a lot of interesting stuff becomes possible, such as the fast file system creation

It takes just a few seconds to erase a disk and initialize it with HFS+, including the creation of the file system. Even on a really big disk you are in and out of Disk Utility in no time. It is so short that you don't budget any time for it, you just do it when you need to. It takes longer to read the "all data on this volume will be destroyed" message than the actual disk activity that follows.

Fast file system creation is one of the things that make disk images possible. You couldn't use disk images as your archive format if it took all day to make one.

The problem with any debate involving HFS+ is that the volume format has an undeservedly bad rep. One reason for this is that it was introduced with Mac OS v8, yet many key features lay essentially dormant until 3-5 years later with Mac OS X. Everybody thought HFS+ had a 31-character filename limit, but that was a Mac OS 9 limitation, not an HFS+ limitation.

Another reason for the bad rep is that HFS+ was developed specifically for graphical desktop computing, whereas many other volume formats are optimized for enterprise computing, or servers, or other priorities. To many geek eyes HFS+ appears to be doing many things the "wrong" way. For example, every file on an HFS+ disk is identified not only by filename but also by node number, so the user can rename or move a file or application (even while they are open or running) and the system and apps continue to find it by the node number. This is why you can close iTunes, move your whole music library folder to a new location on the disk, and then open iTunes and it will still immediately find all of your audio files, even though each and every single one now has a different pathname. This is actually the most underrated feature of the Mac ... for over 20 years these HFS nodes have been responsible for an almost unimaginable amount of non-problems and non-support-calls. It makes the Mac appear to be 1000x more intelligent than other computers in everyday use.

Re:that's nice. now fix network file systems.

[Wakko Warner]

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.

Things like this can be fixed by setting applications up properly. In this situation, I would be using IMAP, not NFS.

Re:that's nice. now fix network file systems.

[dschuetz]

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.

Things like this can be fixed by setting applications up properly. In this situation, I would be using IMAP, not NFS.

I do use IMAP, and Mail.app talks to it just fine. The problem arises when I'm using Mail.app to read email from two boxes at once, both operating out of a network-based home folder. The app has some cache/index files that don't play well in a sharing environment.

I'm slowly coming to the unhappy conclusion that, at least for home folders, I'm going to have to keep everything local to each box and just make it easier to copy documents, etc., to a network-based home. Downside: all prefs, etc., will be local to the box. Upside: I can leave myself logged in on two different levels of the house w/out worrying about one copy of an app trashing temporary/"local" files and crashing the other copy.

To answer the question about filing bug reports: 1, I'm skeptical about it even doing any good, and 2, I haven't really gotten around to taking careful measurement of exactly what's going on. Maybe some day I will, but for now, I've got way too many other things on my plate.

As for Coda -- interesting filesystem, but I'm really not ready to put a research project on my network as the primary way for moving files around. :)

Re:that's nice. now fix network file systems.

[Unknown Relic]

Right now, I'm using a Linux server with three Macs (two Tiger, one Panther), and everything is over NFS. Most of the time, it works fine, but if there's a weird hiccup, then the Mac will freeze solid and has to be hard power-cycled.

This issue has to do with how you're mounting the NFS share. In particular, it sounds like you're using the hard mount option when what you want is soft. If hard is specified and there's an issue the client will stop and wait for the nfs server to be available again before allowing the action to continue. Soft on the other hand will time out and display an error if the NFS server an issue occurs.

Re:HFS+ vs. UFS vs. ZFS

[minus_273]

flamebait??? huh? someone try to install windows media player and get the UFS warning. If you cant click on the link, there is the text from MS:

UNIX File System is not supported
Windows Media Player for Mac OS X does not support the UNIX File System (UFS). Install the Player on a Mac OS Extended (HFS+) volume only. HFS+ is the default file system format for Mac OS X.

jeez.

Re:HFS+ vs. UFS vs. ZFS

[Just Some Guy]

Gotcha. I was hoping you'd say something like "using case-sensitive comparisons makes it less painfully slow" or something along those lines. I love our little LCD iMac, but backups border on painful ("the thing is still in the estimate phase?!?").

Apple should just buy SUN

[adam1101]

The more I think about it, the more it makes sense for Apple to buy SUN. Their products nicely complement each other. Apple is strong in the consumer market and in the creative sector, SUN has good presence in the enterprise, tech and finance sectors. Apple has great brand value and knows marketing like no other computer vendor, SUN has technical excellence, but it's been struggling in the last years to actually sell their stuff. Their products portfolios have little overlap, and together they offer a very complete spectrum of computer products.

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 caps, Apple can afford it.

Re:Apple should just buy SUN

[mhollis]

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!

Re:Apple should just buy SUN

[spud603]

I remember a time not too long ago when Apple was about to die and everybody was talking about Sun bying Apple.
Oh, how times change.

Re:Apple should just buy SUN

[Faithman2k]

But I thought Google was buying Sun??

Click on the following article link for details http://blogcritics.org/archives/2006/02/26/123335. php

Re:that's nice. now fix network file systems.

[Unknown Relic]

Soft on the other hand will time out and display an error if the NFS server an issue occurs.

Well that's what I get for posting before my morning coffee. That bad attempt at Yoda-speak should read: "Soft on the other hand will time out and display an error if an issue with the NFS server occurs."

ResEdit

[Kadin2048]

Ah, ResEdit. I have a warm place in my heart for that program.

The mischief that a person could create with a few dumb ResEdit hacks.... priceless.

unfounded opinions

[dottedlinedesign]

But Dvorak said Apple was switching to Windows! How could this possibly be true?

BeFS

[Kadin2048]

I thought that the big benefit to the BeOS FS was that it had support for an arbitrary number of metadata fields and forks, and HFS+ does that right now (if you wanted it to). The examples I always saw as to why the Be FS was going to be "cool," to a user's perspective, were things like viewing a list of MP3 files from within the OS's file manager: rather than storing Artist, Title, Length, etc., as ID3 tags, viewable only within an application that parsed the file, you could store the fields as file metadata and then use them at the OS level rather than the application level to view / sort / search / whatever. Similarly you could do the same kind of thing for any kind of file, and anyone (with the OS) would be able to read it regardless of which applications they had or wanted to use. It was kind of a neat concept (interoperability problems with other OSes excluded) but as much as I love metadata, it seems like that's not the direction people are going in.

What were the other reasons it was going to be cool, and which of those reasons aren't covered already?

Re:BeFS

[TheRaven64]

BeFS didn't have resource forks (a good thing, in my opinion), but it did have better support for metadata than I've seen anywhere else. For one thing, there was over 100 bytes in each inode on disk that could be used to store arbitrary metadata (in typed key/value pairs). Since you needed to load the inode for most file operations, this is very fast. How long does it take to do ls -l? That's exactly how long it took to load arbitrary metadata about the same number of files in BeFS.

The other really nice thing was that the creation of indexes was very simple, and once created, any modifications to the metadata of a single file would automatically be reflected in the index. Oh, and the indexes were stored in exactly the same way as directories, so they were easy to get at.

The one thing I didn't like about Be's implementation was that their adaptors (things that translated between FS metadata and things like ID3 tags) had to be manually invoked. I would have made them daemons that would have scanned an index of recently modified files.

Beyond that, BeFS was a nice clean 64-bit UFS-like filesystem.

Re:dunno bout m$...

[Jay Maynard]

Why do you care? Why not do as your users expect and ignore case when comparing?

Computers exist for people, not vice versa.

Re:HFS+ vs. UFS vs. ZFS

[Whiney Mac Fanboy]

People still use Classic? I haven't used the Classic environment since 10.0 shipped.

Thanks for that! Super-helpful.

Nothing like being told you don't need to do something you're doing.

Re:Tiger Filesystems (10.4.6)

[aibrahim]

Ugh... I tried reposting listing anonymously for a higher rating, but I forgot that posting as AC removes karma and logged in bonus... so here I go being TREBLY redundant.

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 /System/Library/Filesystems/
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 4 02:45 afpfs.fs -> /System/Library/Filesystems/AppleShare/afpfs.kext
drwxr-xr-x 6 root wheel 204 Feb 24 22:08 cd9660.fs
drwxr-xr-x 3 root wheel 102 Mar 26 2005 cddafs.fs
drwxr-xr-x 4 root wheel 136 Nov 4 02:45 ftp.fs
drwxr-xr-x 5 root wheel 170 Nov 4 02:45 hfs.fs
drwxr-xr-x 4 root wheel 136 Mar 26 2005 msdos.fs
drwxr-xr-x 3 root wheel 102 Mar 20 2005 nfs.fs
drwxr-xr-x 6 root wheel 204 Sep 4 2005 ntfs.fs
drwxr-xr-x 3 root wheel 102 Mar 26 2005 smbfs.fs
drwxr-xr-x 6 root wheel 204 Apr 29 21:33 udf.fs
drwxr-xr-x 4 root wheel 136 Mar 20 2005 ufs.fs
drwxr-xr-x 4 root wheel 136 Mar 26 2005 webdav.fs

File Vault

[man2525]

I have to wonder if ZFS would help FileVault operate more eficiently. I now have the option to free up slack space in my encrypted Home directory when I shut down my computer. Would ZFS eliminate this step?

Re:HFS+ vs. UFS vs. ZFS

[cypherz]

So do you still use Classic or are you just being a smartass?

Re:that's nice. now fix network file systems.

[Seanasy]

Coda is the successor to AFS though I doubt it's much easier to administer.

Re:HFS+ vs. UFS vs. ZFS

[drinkypoo]

People who don't know what they're talking about shouldn't moderate. They can go mod someplace where they do know something. Alternatively, it is possible to use google so that you do know what's going on, and then moderate accordingly, instead of being a dumbfuck.

Lies or Lack of knowlege???

[John Jamieson]

OK, so I had to choose whether to mod parent down(+4, Interesting)???, or inject some reason into the thread. A tough decision!!!

Unlike Open Source projects Apple has to do a lot of regression testing and QA

OK, the previous post is sounding a bit like fanboi apologetics(or a troll).
Any software that is going to be upgraded needs QA.
Bugs do not give Open Source software a free ride. Do NOT believe the the BSD or Linux guys ignore regression and QA testing anymore than any commercial vendor. I write for a commercial company, and end up doing too much testing(in my opinion), but we don't pump out code near as solid as the BSD or GNU/Linux guys. They obviously do a LOT of testing.

If Apple took the Linux approach, OS X would run ...five filesystems ... and would be hated by typical users for the brief time Apple was around
You cannot convince me that most Apple users feel that having a variety of filesystems (which are transparent) would make them hate the OS. I would like to give more credit to the user base than that.


I was just talking about this to the City Manager in Tuttle, and he claimed that the Open Source QA testing was so good because "these freaks have nothing better to do". (ok, I wasn't, I just wanted to laugh at Tuttle, but it would explain the quality)

Re:Lies or Lack of knowlege???

[BrainInAJar]

we don't pump out code near as solid as the BSD or GNU/Linux guys. They obviously do a LOT of testing.

There's an army of ricers to do their testing for them (I'm actually not judging, I do it too on occasion... i'm running a ck kernel at the moment). Commercial companies have to pay their testers

ZFS: Finder == Horse: Jockey

[ElitistWhiner]

Apple is merely picking their horse before they mount their jockey. ZFS is transaction oriented which tells us something about the future. Apple is in the transaction business (iTMS, .MAC, AppleStore, etc...). Expect one hell of a shopping, business centric user experience if they bolt ZFS onto OS X and a killer new user interface to replace Finder.app.

Apple the corporation could "own" the layer above transactions taking a micro percentage in rent/toll for making the experience profitable (ala iTunes).

Re:HFS+ vs. UFS vs. ZFS

[Azarael]

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, but the as the guidlines say http://slashdot.org/moderation.shtml/ in the FAQ, question 5:

What is a Good Comment? A Bad Comment?
* Good Comments are insightful. You read them and are better off having read them. They add new information to a discussion. They are clear, hopefully well written, or maybe amusing. These are the gems we're looking for, and they deserve to be promoted.
* Average Comments might be slightly offtopic, but still might be worth reading. They might be redundant. They might be a 'Me Too' article. They might say something painfully obvious. They don't detract from the discussion, but they don't necessarily significantly add to it. They are the comments that require the most attention from the moderators, and they also represent the bulk of the comments. (Score: 0-1)
* Bad Comments are flamebait. Bad comments have nothing to do with the article they are attached to. They call someone names. They ridicule someone for having a different opinion without backing it up with anything more tangible than strong words. Bad comments are repeats of something said 15 times already making it quite apparent that the writer didn't read the previous comments. They use foul language. They are hard to read or just don't make any sense. They detract from the article they are attached to.

By the above def, the grandparent is no more than an average comment that maybe leans a bit towards flamebait and probably shouldn't have been modded up or down.

Re:HFS+ vs. UFS vs. ZFS

[minus_273]

we are talking about filesystem compatibility on OSX. Anyone who has looked into it knows the problems with certian OSX software and UFS. My only mistake was assuming there were more people who actually know what they are talking about. Only on slashdot can I get moderated framebait for reiterating something stated as fact in the software's own manual.

Re:DeRez, RezWack, SplitForks, etc.

[JambisJubilee]

There's a bunch of resource fork utilities in /Developer/Tools/. Just add it to your $PATH

Re:HFS+ vs. UFS vs. ZFS

[Azarael]

That's true, unfortunately the comment happened to appear to be a lot like a lot of the flames that get posted. It takes a lot of time to mod something properly, so mods jump the gun sometimes.

Database filesystem

[codemachine]

Considering that Apple has been working on a database file system (like WinFS, except that it'll actually be released), I'm not sure where ZFS fits in here. Maybe on XServe and XServe RAID, or just as another alternative besides HFS+ and UFS I suppose. But I don't think the dbfs will be based on ZFS.

Re:that's nice. now fix network file systems.

[imroy]

I do use IMAP, and Mail.app talks to it just fine. The problem arises when I'm using Mail.app to read email from two boxes at once, both operating out of a network-based home folder. The app has some cache/index files that don't play well in a sharing environment.

If that's the case, then it's an application issue. No new network filesystem is going to magically fix bad assumptions made in an application. Go complain to Apple or whoever it is that makes Mail.app.

Re:HFS+ vs. UFS vs. ZFS

[CableModemSniper]

._filename is how apple encodes the resource-fork on non-HFS+ filesystems.

Re:dunno bout m$...

[Jay Maynard]

Why do users not expect case to matter?
Because it doesn't in real life. That's why people have such a hard time with the concept. To the average user, there is no difference between Setup.exe and setup.exe, and having the two do different things violates the principle of least surprise.

Re:dunno bout m$...

[Mr Z]

Why do users not expect case to matter? Could it be that users learned based on the first OS they used? If case was required on the computer, users would have no problem with case sensitivity.

The first computers I learned on didn't really support lower-case well. (TI-99/4A, Apple ][, Commodore PET/VIC-20/C64. PETSCII anyone?) That's a different sort of case-sensitivity, though. So about "My first computers didn't handle lower-case well, you insensitive clod!" ;-)

At a minimum, I want my file system to preserve case. If there sare any ambiguous/locale-dependent toupper/tolower conversion for a given legal-in-a-filename character, then the file system should also be case sensitive. I know English's toupper/tolower is well defined (and pretty damned easy in ASCII), but what about other languages? After all, we could use Unicode filenames.

--Joe

SSHFS

[booch]

I want SSHFS, dammit! I've got SSH set up on pretty much every system I have. It's simple, and it's encrypted. What more could I want? Oh yeah -- seamless SCP/SFTP clients.

Re:SSHFS

[rmm4pi8]

Works on KDE as a kio-slave. Just use fish:// in Konqueror or a file dialog for access. And before you say something about how this is a Mac discussion, remember that KDE runs on Mac :-). But yeah, I often find myself wishing for that feature when I'm forced to use a Windows system.

Re:SSHFS

[booch]

I was not aware that KDE ran on Mac OS X. I assume it runs on top of X11, which I'm not terribly fond of running on my Mac. It wouldn't be so bad, if there was a decent SFTP/SCP client for Mac OS X. I tried a few, but the only one that was decent had 15% of the performance of the command-line SCP. On Windows, I find WinSCP to be good enough to keep me from complaining.

Re:that's nice. now fix network file systems.

[TheRaven64]

Apple pretty much ignore things sent to http://www.apple.com/macosx/feedback/. They do a slightly better job of fixing things filed at http://bugreport.apple.com/, but I still have a dozen or so unfixed bugs there, some over a major version old.

AFS is NOT complicated...

[rmdyer]

"There's always AFS, but that's so bloody complicated that I'd take a lot of convincing before I seriously considered it."

AFS is NOT complicated. There are some people who for better or worse have made it seem complicated. There are some simple principles you need to understand before you use AFS, and after that it's generally a great ride.

Historically, there are three databases that must be managed. One of the databases manages the user accounts, and groups. The next database handles the volumes, what servers the volumes are on, how big the volumes are, and how the volumes are mapped into the AFS tree. And the last database is KAS, which is now defunct since Kerberos is used instead. These databases are managed as a group called a CELL. An AFS cell is simply a designation similar to a domain name, that groups all the volumes and security principles under one umbrella. You can build multiple cells if you want.

Some AFS features...

* Global namespace
      One mount path gets you everywhere.
      Continuously mountable.
* Read-only replications with failover.
* Volume level user quota.
* Directory level ACLs.
* Administrative and user creatable groups.
* User managable groups.
* Unix style symbolic links.
* Kerberos authenticated security.
* Integration for heterogeneous environments
      of Windows, Unix, and Mac OS X.
* Encrypted network transfers.
* Internet wide file sharing with other
      AFS institutions and businesses via the
      standard "/afs" mount.

The people who have made AFS overly complex should be shot. There are people who try to preserve their lives in the industry by building complex systems, then they make themselves out to be authorities (gurus). Many people involved in AFS are of that nature, but I assure you, if you think AFS is complicated, then you might as well be using Windows wizards. Real sysadmins learn the tools of their trade, and AFS is a very good tool to use.

Just my 2 cents.

Re:AFS is NOT complicated...

[pjl5602]

While AFS might be fine in a larger environment, what the grandparent poster describes was a small setup (one Linux server and 3 Mac OS X clients.) AFS is awesome. Doing a 'vos move' on an live volume and the clients don't miss a beat is to die for... However, I not sure it's not worth doing for such a small setup. I would maybe like to run AFS on my home network, but I just don't think it's worth doing. I only have one server at home acting as a file/print/mail/web server for a few client boxes throughout my house. If I put AFS volumes in place to replace my existing ext3 file systems (years ago AFS did not map metadata over existing filesystems as DFS did) there wouldn't be a strong enough benefit for me to disrupt everything. At home, SFTP/SSH and SMB work well for my environment. I keep expecting NFSv4 any day now that does what AFS does but that day never seems to come...

Re:HFS+ vs. UFS vs. ZFS

[dloose]

<< "UFS is case-sensitive"

< Why is this a problem? I've been living with case-sensitive systems
< for years.
< Never been a problem before.

I've run into issues with a few poorly-coded applications that assume case insensitivity. For example, Big Bang Chess has issues loading textures on a case-sensitive HFS+ filesystem but none a case-insensitive one. So, yes, problems do exist, but they'd quickly go away if Apple forced case-senstivity on its users.

Re:that's nice. now fix network file systems.

[Arandir]

I agree. While NFS is nice, it does have some problems, particularly in the area of security. Samba just a big reverse engineered hack. A new modern network file system for ALL operating systems would be great.

Re:YAY!

[TheRaven64]

The problem with resource forks is that they are, effectively, directories. It is generally considered a bad idea for a low-level system to have two ways of doing the same thing; it's more low-level code to make correct and fast, and the high-level developers aren't often sure which is the correct one to use. Since resource forks aren't folders, you need an extra set of tools for looking inside them, etc. It's needless complexity.

In effect, a resource fork is a directory which is allowed to contain binary data as well as children. If this is seen as a good idea, then the correct way if implementing it is to allow any file to act as a directory (actually, this is exactly what I would like to see - a filesystem where parent-child relationships are arbitrary metadata, not special cases).

beyond RAID in data integrity, self-healing

[toby]

Apart from those pluses mentioned by lokedhs (snapshotting is no trivial feature to have, if you're running databases, for example, or want admin abilities like rollback) - What ZFS offers that no other Linux filesystem offers, let alone HFS+, is end-to-end data integrity and self-healing. That's why I picked Solaris 10 for a high-integrity database app recently. Nobody else could offer the integrity guarantees (apart from some SAN vendors perhaps).

Partition Resizing

[TwinkieStix]

Listening to TWIT I heard a conversation about Parallels and dual booting. Although, obviously not an authoritative source, there seem to be some problems resizing the standard OS X file system for adding Windows to Macintosh computers. Perhaps the resize issue is something they are trying to fix by switching to a more advanced FS? Does anybody know if this makes ZFS more valuable to Apple?

Re:dunno bout m$...

[Minstrel Boy]

"People just don't think that way until they've been conditioned to do so by Unix."

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 written romance languages, use capitalization explicitly throughout their lives. You can argue that they don't think that way until they've been conditioned by literacy, but don't drag Unix into it.

KeS

Re:dunno bout m$...

[Jay Maynard]

People don't use capitalization to distinguish between two different words, however. Capitalization in a written Romance language is nothing more than a grammatical flag. If it were more, it would need to cause difference s in pronunciation, and it does not.

XServe

[gwhenning]

Perhaps they just want you to be able to take your SUN systems, pull the drives, throw away the box and pop the drives into an XSAN to migrate all of your data over to XServes.

Hardlink Shell Extension

[hackwrench]

http://schinagl.priv.at/nt/hardlinkshellext/hardli nkshellext.html
Problem solveed, though it is neither a Microsoft-produced nor open source solution.

Re:Hardlink Shell Extension

[Lucractius]

funnily enough im well aware of this... im perfectly capable of using this or one of 4 other soloutions i have found... the danger is that windows itself blindly follows these links with no real intelligence, the filesystem is fine with them... the applications on the other hand are utterly ignorant of the possibility since NT apps were never designed with full POSIX compliance so a recursive operation on any file that traverses a hard link will create misleading drive semantics. and as the user of an automated drive performance maintenance tool... BAD move for me. I cant rely on my copy of Diskeeper to handle Hard links or Soft Links and untill i can, theres little point me risking data corruption by playing with experimental and "unsupported" file system structures.

Re:OT: Context switching...

[Myria]

Task switching between the monitor and the virtualized task is much more expensive than a user-kernel-user switch.

Melissa

They already are like directories

[Myria]

In OS X, you access the resource fork by opening filename/rsrc with open() or whatever. In 10.4.x, you can have other files inside that file.

In Windows NT on NTFS, it's similar, except rather than / it's :. You can in fact copy Mac files as filename.txt:rsrc if you wanted.

Melissa

Must I state the obvious...?!!!

[MAC1337]

All these posts from smart people and nobody's yet mentioned the single biggest reason for Apple to integrate ZFS; to download the internet to that puppy of-coarse! -Leety

ZFS on a {Power|Mac}Book{| Pro}

[Gekke Eekhoorn]

The rest of the stuff, pooling and mirroring and stuff is less interesting in my laptop. :-)

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:

1. Find an external disk that is at least as big as your laptop drive. For example, a 6th Gen iPod ;-) (You could also protect only part of your disk, by partitioning it)
2. Now create a mirrored ZFS pool containing your laptop drive and your iPod. This pool is where your ZFS filesystems get their storage space.
3. Now, every time you want to do a backup, simply connect the iPod. ZFS will see the re-attached mirror, and synchronize all changed blocks.
4. If your laptop disk breaks, simply mount up your backup disk, and you will have all of your data AND all of your snapshots.

See? It can be that simple. And there's more:

• ZFS is always consistent on-disk, unlike any other filesystem. So you can unplug that iPod at any time, no harm done.
• ZFS keeps checksums of everything, and is both the filesystem and the volume layer. This means that as soon as the data leaves the application, it is safe from undetected changes. No more bitrot.
• You can have as many ZFS filesystems as you like, and each has independent snapshots. You could keep a snapshot of your $HOME/Documents/Important folder for every minute, if you make it into its own filesystem, and just make a snapshot of your root filesystem just before you upgrade your OS/install updates.
• Compression can be enabled per-filesystem, which is great for laptops. Compression means higher read bandwidth and more diskspace.
• Encryption is being worked on and will be per-filesystem. Apple's Filevault encryption is ok, but could do with a lot more stability.

So what if ZFS does things that VMS did. No-one else has made anything quite like the summit of cool stuff that ZFS is. Apple makes a living bringing cool stuff together and making it cooler. It's a natural match :)

ZFS would yet again boost OS X's position as ultimate laptop OS. Here's hoping that Apple does implement it.

Re:dunno bout m$...

[Jay Maynard]

In computing, case sensitivity makes capitalization more than a grammatical flag. It alters the meaning of a word. That's exactly what it does not do in the real world.

Languages in the real world aren't just written. They're spoken. There's no difference at all between Romance (as in language) and romance (as in the art of love) when one speaks the words; you must differentiate by context alone. The capitalization of nouns in German is similar.

That's why the average non-computer-geek gets confused by case sensitivity (and the average computer geek who didn't start out on a case-sensitive OS).

Re:HFS+ vs. UFS vs. ZFS

[Pope]

I use Classic all the time, as do a lot of others, I suspect. Stop being a smartass.

The greatest UI botch in UNIX

[tlambert]

"Case sensitivity is the single greatest user interface botch in Unix"

The greatest UI botch in UNIX is actually not doing it's regex expansion below the user/kernel boundary. It means that you can't do interesting things, like only copying back the directory data that matches your regex across the expensive protection domain crossing of the U/K boundary. It also means that you can't do *very* interesting things, like real versioning support at the FS layer (unless the name you're looking up is considered a regex, you can't default the version suffix in the name space, like VMS did).

The second greatest UI botch was puting the processes environment in user space, and exposing a "char **environ" variable into the process name space, so it was impossible to move the implementation into the kernel proper, and deal with environmental inheritance, like the historical process, group, and system logical name tables. Without this, it is practically impossible to provide reasonable support for things like variant symbolic links.

The third greatest UI botch was vowel compression in command names to fit them into the 14 character file name limit.

The fourth greatest UI botch was not having a regular command line argument syntax for all commands.

I could continue on the whole top-20 list, but I won't.

Case sensitivity, on the other hand, is what makes 7 bit NRCS-based internationalization, UTF-8, and other arbitrary character set encodings work so well. Windows has to carry around encoding tables for its encoding tables to deal with it's 16 bit Unicode characters vs. the current code page, in order to represent a locale, and it's limited to the early Unicode specifications because it doesn't support the full 32 bit wchar_t type.

UNIX made a lot of early mistakes, which, as engineers, we've stupidly carried forward with us instead of correcting, but initial case sensitivity for file names wasn't among them.

-- Terry

Re:The greatest UI botch in UNIX

[Jay Maynard]

If you want Very Messy Syntax, you know where to find it.

The benefits of case senaitivity are purely accidental, and can be dealt with in software. Breaking users' expectations for how things work cannot, and causes far more lossage than fixing the things you cite as benefits.

Re:The greatest UI botch in UNIX

[statusbar]

I like how case-insensitive systems properly compare the German 'B' (beta-like symbol) with the equivalent lowercase 'ss'. That is handy.

Unfortunately the problem comes when you try to untar or copy a linux kernel source tree, where the netfilter directory is filled with multiple files differing only by case! ipt_ECN.c and ipt_ecn.c are different files! subversion svn co fails and halts, cvs co fails silently later. tar silently erases...

--jeffk++

Re:The greatest UI botch in UNIX

[Jay Maynard]

Programmers who commit atrocities like that one should be horsewhipped.

Re:that's nice. now fix network file systems.

[Scudsucker]

Well I'm up way too late and I understood your origional comment just fine.

Lesson learned: sleep is overrated.

Re:that's nice. now fix network file systems.

[The Ego]

In addition to the other replies regarding Coda and AFS, it should be mentioned that NFSv4 is a much-awaited improvement on NFSv3. It could turn NFS into a real alternative to SMB/CIFS in LAN setups and maybe even WebDAV in WAN setups (e.g. as in Apple's iDisk).

It supports ACLs, real/robust file-locking, encryption and authentication, compound RPCs to reduce network round-trips.

NFSv4