Over the past couple of years, the usurpation of the current Mac's HFS+ file system by Sun's ZFS has been predicted. Sometimes that message has been delivered (incorrectly) by Sun top brass.
While Mac OS X 10.5 Leopard Server supports ZFS, there's no expectation that it will replace the current Mac file system any day now, or even any year now.
A recent Ars Technica article by Jeremy Reimer provides an overview of the file systems used by many platforms, including Macs, PCs and Unix systems. He discusses the merits (and historical context) of each, as well as the chances for adoption of ZFS by Apple.
Reimer asks why Apple didn't switch over to the "newer and sexier" ZFS a few years ago instead of continuing to refine HFS+. He suggests that it's an uphill task to move a user base to a new file system. For example, long-established file systems, such as FAT, still can be found in popular peripherals including flash drives.
Often it is easier to stick with well-established file systems, even when the cost of switching is ostensibly "free." The example of Linux, which is completely open source and allows anyone to write a new file system for it, is a useful one. Despite valiant attempts to establish ReiserFS as a new standard, and the measurable superiority of systems like XFS, most Linux users are still using ext3. ext3 is not new. It's not super fast. It's not sexy. It won't cook your dinner. But it is tried and true, and for many people, that is more important.
NTFS is likely to stick around for many years in the future, simply out of sheer inertia. HFS+ may kick around for a few years longer as well. Even FAT may still be on our thumb drives, haunting us with the ghost of CP/M long after everyone has forgotten what that even was.
Reimer may be overly optimistic in his time frame. Changing almost anything in the installed base and the developer base is difficult, and even an easy transition will extend over many years. Transitions that concern storage are usually even tougher.
Here are some selections about the Mac's file systems from Reimer's interesting article:
Reimer runs down the challenges of the early Mac file systems. Old Mac hands knew lots of things about the "forks" introduced in the Macintosh File System and then continued in the original Mac Hierarchical File System (HFS). Each file had two forks: a data fork with the actual data, and a resource fork that held meta data about the file, including its icon. I mentioned this the other day in a post about Leopard's icons.
HFS didn't mess around with slashes or backslashes to separate directory names. Instead, it used a colon (:) and then made sure that the humans would never get to see this letter anywhere in the system, until they tried to include one in a file name.
All kidding aside, HFS was the first instance in history where a file system was designed specifically to adapt to the needs of the then-new graphical user interface. The whole philosophy of the Macintosh's GUI design was to hide unimportant details from the user. This "human-centric" design was intended to help people focus more on their work than the technical details of the file system.
Reimer also talked about the different file systems used by NeXT and then Mac OS X.
Over time, the influence of the NeXT people waned, and some of their hard-line decisions were revisited. UFS support was finally dropped in Leopard, the latest version of OS X. File extensions, while still supported, were no longer mandatory.
There was still the issue of bringing HFS+ up to more modern standards. In OS X 10.2 (Jaguar), journaling was added to the file system, although it was turned off by default and could only be enabled via the command line. In 10.3 (Panther) it was enabled by default. Apple also hired Dominic Giampaolo, co-creator of BFS, and he worked to add extensible metadata, journaling, the initial implementation of Spotlight, and FSEvents. Lastly, NTFS-style fine-grained file permissions were added in Mac OS X Server 10.4.