Virtues of Journalling
I've seen a fair amount of debate on the web regarding journalling on HFS+. On the one hand, it is obviously a good thing to have. On the other, softupdates plus snapshots give you all the benefits of journalling without the performance hit.

It seems to me (speculation only) that Elvis is indeed most likely the work of Giampaolo, and comes from the BeOS camp, rather than Jordan Hubbard's FreeBSD side. And, while I would prefer not to have the performance hit that accompanies Elvis, I have to say that if this is the first step towards a rewrite of HFS+ to include BFS's handling of metadata, then I for one am happy to take the hit.

So the question of the day is, do you think that this is indeed the first step towards integrating the rest of the goodies of BFS? Or do you think that this announcement is simply an event in a vacuum?

I'm not sure...
I don't think we know how much Journaling slowed down the BeFS, since they didn't ship without it, and we never saw comparisons against a tuned version without Journaling...

Disappointed to see HFS still being enhanced
To provide a contrary view, I hope that this is the last enhancement to HFS that we see from Apple. The primary benefit that I see with HFS is backward compatibility, not compelling features that are unavailable in other filesystems. Resource forks provide some interesting capabilities but break many Unix tools like rsync or tar.

I would prefer Apple further embrace the Unix aspects of OS X and adopt the enhancements to UFS being made by the FreeBSD group and others, e.g. softupdates, UFS2, and TrustedBSD's ACLs.

I am not sure how high the cost of dropping HFS is, though. How do your favorite applications use resource forks? Could these features be supported in UFS2's extended attributes?

Virtues of Journalling
I think Apple's userbase has made it abundantly clear that they want metadata, and no one argues that Be's was the best metadata implementation ever. There are multiple ex-Be engineers working at Apple. It would not surprise me to see more BFS features incorporated into HFS in the future, especially with Microsoft moving to a SQL database filesystem in the future (with Longhorn).

I'm not sure...
Scientifically, you're correct - we never saw a BFS without journaling. Empirically, we know BeOS could boot to a full GUI in 15 seconds and that apps launched in the blink of an eye, even with full journaling, which is why I say that journaling in BFS didn't incur a performance penalty.

BFS Performance
Scott, you wrote:
"Empirically, we know BeOS could boot to a full GUI in 15 seconds and that apps launched in the blink of an eye, even with full journaling, which is why I say that journaling in BFS didn't incur a performance penalty."

I don't think the journaling mechanism should have any impact on those two operations. Journaling only comes into play on FS writes. Not many FS writes on launching an app.

HFS is best for now
This is more of a response to the post "Disappointed to see HFS still being enhanced."

I did format my OSX drive UFS at one point because we all know about some of the downfalls of HFS (darn b-trees) and i knew that all in all, UFS generally has less problems. However, over a period of a few months, I noticed some major problems with this decision. A few programs would refuse to install saying "'/' is a network drive and this program can not install to network drives." It also seemed that in place of the resource fork, an OSX invisible file was created for just about everything which made copying files between computers, and viewing directories via ssh or ftp a pain. Also, boot time was significantly increased.

Given, these are all things controlled by the OS, so they could be altered by Apple to be more compatible with a UFS file system. But for now, I'm sticking with HFS.