Matt Dillon: I would not characterize soft-updates as being a step-ahead of journaling. At least not meta-data journaling. It's just another way of doing things. Even though soft-updates can theoretically perform better then even meta-data journalling the plain fact of the matter is that linear disk bandwidth has at least 25x the throughput of a random seek/write. So journaling meta-data has a fairly small performance impact if you can asynchronize everything *else*. Softupdates works extremely well for UFS but the softupdates concept can break down with other filesystems - it could very well be impossible to implement softupdates-like operation on a filesystem which implements directories as BTree's or hashes, for example. On the other hand softupdates can commit meta-data operations out of order while still maintaining filesystem integrity, and it can do it in an infinitely fine-grained fashion which naturally leads to better parallelism. Journaled filesystems typically can't do that. So the usefullness of the theory depends heavily on what your goals are. For general purpose work both theories work equally well.
Most filesystem-specific 'super' features are highly specialized and not actually useful in the vast majority of system installations. XFS has data zoning features and (at least under IRIX) the ability to guarentee data stream latency and bandwidth. I can count the number of applications that actually need those features on one hand with a few fingers cut off. XFS's major advantage, as with all journaled filesystems, is instant crash recovery. All else being equal this is a journaled filesystem's biggest advantage for general purpose computing but, even so, supplying the proper options to newfs when creating a UFS filesystem can drop fsck times by an order of magnitude on large filesystems. People using UFS are not really at that much of a disadvantage. You can't provide any sort of Q.O.S. if you depend on fast crash recovery to be fast. Q.O.S. means having redundant hardware at the very least. I can't comment on JFS, I've never used it.
All of the BSD camps make stability priority #1 and performance priority #2. Performance and fast crash recovery is completely irrelevant if the filesystem corrupts the data or causes a crash! This is especially true as HD capacities increase and filesystems become larger. I have never quite understood why the Linux community gets so revved up by the huge number of filesystems they support. As if the sheer number combine together to provide a more effective system! You don't get reliability, performance, and long term stability by playing with filesystems, you get it by choosing or focusing on one or two filesystems that deliver those characteristics. Depending on filesystem-specific 'super' features makes code non-portable and is not usually a good idea.
In anycase, most BSD developers are happy with UFS. Oh, when I say UFS I really mean UFS+FFS or UFS+FFS+SOFTUPDATES. UFS is not the ancient creaking beast that some people have stereotyped it as. The basic theory and structure was sound and is still sound to this very day. Over the years we've fixed bugs (what few bugs we find), added capability support, better caching, reorganized the layout in a backwards-compatible fashion, re-introduced reblocking (basically on-the-fly defragmentation), softupdates, snapshot support, etc etc etc.
4. After the open source bubble bursted recently, a lot of companies seized support and stoped contributing code to both Linux or BSD. How has this affected the BSD development?
Matt Dillon: It creates a short term disruption for the people involved in regards to their ability to contribute but I do not believe company layoffs will have any effect on the open-source movement itself or on Linux and BSD development in the long term. The biggest contributors to open-source are not staple employees of a company who are hired specifically to interact with the open-source community. They are people who have a real interest and love of open-source who happen to be working at a company in a leverageable position.
While there have been BSD related layoffs, it's nothing that was unexpected and has had much less of an impact on us then I'm sure the huge number of linux-centric companies going bust has had on the Linux psyche. All I can say is: It aint our (the open-source community) fault. Most of the linux centric companies were leeching off the linux name, and those that weren't didn't fail because they were using Linux, they failed because they didn't have a business model with a chance in hell of (ever) going profitable. Open-source operates behind the scenes far more then it operates in the public eye, and it's hard to sell support to hackers who actually have *fun* trying to figure out a problem. In some respects Linux and the BSDs are poor commercialization candidates because they are *too* good... that they simply do not require the level of support that something like Windows-NT or Oracle might require in a back-office setting.
Open source has created far more disruption and change in commercial interests then the other way around. I think it has been for the better, though I'm sure many commercial entities (such as MS) aren't too happy about being forced to be more honest with their customers. (hmm... actually I think they still haven't learned, and look at the effect. MS has gotten its fingers burned so many times in their dirty war against open-source that even long-time commercial partners don't believe what they say any more!).
- "Matt Dillon, VM and kernel FreeBSD team, Part I"
- "Matt Dillon, VM and kernel FreeBSD team, Part II"
- "Matt Dillon, VM and kernel FreeBSD team, Part III"
- "Matt Dillon, VM and kernel FreeBSD team, Part IV"
- "Itojun, NetBSD Core Team"
- "Theo de Raadt, OpenBSD Founder"