1. What goodies BSD 5.0 is going to bring us?
Matt Dillon: There are at least a dozen projects going on in parallel and we have ripped up and replaced a great deal of code all over the kernel. So much so that we recently decided to extend the 5.0 release date another year to give the many projects a chance to get out of development mode and into stabilization mode. Due to this a good chunk of -current's features are also being slowly MFC'd into -stable. Not KSEs or SMPng though. I think Julian's comment in his KSE commit message was something on the order of "X-MFC after: ha ha ha ha" :-)
KSEs and SMPng are the most visible projects (SMPng is being spear-headed by John Baldwin), but we have also done a great deal of work on the network stack, checksum offloading, network drivers (especially GigE drivers), devfs (which is now the default in -current), crypto-quality random number generation, scaleability, and new machine ports. We are actively porting to IA64, PowerPC, and Sparc64, and even though the Alpha is dying away our already-operational (in -stable) alpha port is being actively developed to ensure that our code remains 64 bit clean and to provide ground-breaking work for the other ports.
A good chunk of the work has already been MFCd to stable. For example, -stable can push 900+ MBits (120 MBytes/sec 'netstat -in 1') over a TCP connection on a DELL2550 with GigE using *normal* sized frames (mtu 1500). That's full saturation.
A great deal of filesystem work has also been completed. Filesystem snapshot support (for UFS+Softupdates) is progressing nicely and may prove to be one of the most important new filesystem features in the 5.x system once it stabilizes. There are also two new native features in UFS that have stabilized and have in fact been MFCd to -stable: dirpref and dirhash. dirpref comes directly from Grigoriy Orlov of OpenBSD and reworks the way directories are layed-out on disk, resulting in huge directory and file stat/open/create/remove performance gains. Some filesystem operations have improved by over 60x (6000%), and many of the common ones have improved over 400%. dirhash is a very low-overhead in-kernel whole-directory hashing mechanism that radically improves the performance of directory operations.
There is much more. Some things, like dirhash and dirpref, can be easily MFC'd to -stable. Others, such as softupdate's snapshot support, probably won't be due to major dependancies on other current-only projects.
2. Which is the one feature that you would like most to add to the BSD kernel?
Matt Dillon: I would like to see a native process and device-level descriptor migration capability. This isn't a new idea (few ideas in computer architecture can ever be called 'new'), but it is an idea whos time has come. I would like to see an ability to migrate processes as well as their device-level state and couple that with external rerouting. So an I/O descriptor representing a TCP connection could be migrated entirely off the original machine, for example.
Process migration is a good basis to support Q.O.S. and maintainance issues on todays platforms. As computing hardware becomes more powerful and we run more services (and more connections, and more users) on any given box, the ability to migrate everything off a box in order to take it down for maintainance without users noticing that you are doing it has become the ultimate IT grail. The reason is simple: if you use a modern machine to its fullest potential and the system crashes, you are potentially interrupting thousands of users rather then simply dozens. The concept of the 'maintainance-window' introduces the same problem, even with load balancing and connection management and distribution technologies. The 'maintainance-window' concept is rapidly becoming unacceptable in today's full-on world.
In short, process migration would allow the open-source community to begin to provide Q.O.S. levels that only mainframes can provide today. And if you didn't hear me mention so-called 'clustering' solutions currently available from unnamed vendors, it's because they can't actually deliver these things -- not true Q.O.S. That's my opinion, anyway. Using a cluster to hide the fact that the underlying systems crash regularly is an extremely dangerous way to manage a computing environment.
I'm going to cheat a bit and also give you my #2 feature-wish: I want native filesystem replication. I don't care a whit about common server-based disk store: you don't get reliability or scaleability that way. I want to see distributed (replicated, not partitioned) filesystems that are transactionally coherent, to go along with the process-migration of course :-)
- "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"