Unix File System Issues on Mac OS X?

rlthomps-1 asks: "I've been thinking about reformatting my Mac's hard drive in UFS, since I've seen the option on the install screen. I was looking for advantages of the Unix file system since it sounds like it would have better performance over HFS+. After viewing this Apple kbase article I wasn't so sure. A test system at work won't install software correctly because the drive name is stuck as '/' among other problems. Why would Apple include the UFS option if it offers such reduced functionality, and is anyone out there using it for non-server applications? What for? Are there advantages to UFS on the desktop Mac OS?"

UFS is there for historical reasons

[Matthias Wiesmann]

As far as I understand, UFS support in OS X is mostly legacy: previous versions (Mac OS X server 1.0 for instance) relied more heavily on it. In Mac OS X, HFS+ has been optimised more heavily than UFS.

Also understand that many carbon applications have trouble coping with non-HFS+ file-systems. Here in the lab, I mount my solaris home directory thru NFS, and some carbon apps cannot start from my home directory because of this. Some carbon applications even have trouble with files in this file-system (on bad days Acrobat Reader tells me the file does not exist).

As applications and system frameworks become more file-system agnostic. I suspect Apple will probably put less emphasis on HFS+ and put more effort in other file-systems.

Re:Back in the day...

[ahknight]

Really, is it so hard to have data structures for file io that have more than 31 places for filenames?

With 15 years of code under their belt that relied on just that fact, well, yes.

Re:case sensitivity as a security measure?!

[1010011010]

Case-sensitivity is easy, as it's just comparing bytes. Case-insensitivity is hard for non-English (and the more non-English, the harder it gets) languages, because you have to search through a table of equivalent glyphs. It's a lot more overhead. Also, the Unix core of OSX doesn't use Unicode natively, which adds a layer of complexity.

HFS+ was designed for performance

[Megane]

I think one problem people are having with the HFS+ vs UFS issue is they think "Well, I haven't seen this UFS thing before, and HFS+ has been around for a long time, so UFS must be newer, and therefore it must be better!" All this without understanding one thing about how either file system works.

UFS was included for those few people who needed a real, genuine, Unix file system. It has the "real inodes" and the case sensitivity that Unix apps expect. But (as far as I know), directories are stored as files with a special attribute, all over the disk, just like the MS-DOS FAT file system does. It does things this way after all this time because that's the way Unix has always done things.

HFS+, however, is an extension to HFS to give it a few extra things that it needed to become a serious file system. Stuff like support for volumes larger than 2G, really long file names, Unix file attributes, etc. HFS stores directories in a B-tree file. In other words, it uses a database. This is much more efficient than a bunch of scattered files and inodes holding directory information.

Basically, if you don't know a specific reason why you need UFS, don't use it.