Reiser4 and kernel inclusion
Reiser4 is an interesting filesystem. It comes with claims of improved speed and space utilization; those are welcome, but they are beside the real point. Reiser4 includes a "wandering log" mechanism which provides journaling capability without the need for a separate journal. The ability to perform multi-step transactions is built into the filesystem, though not yet completely exposed to user space. Multi-stream files (including file-like access to file metadata) are supported, though this feature is turned off for the moment as well. A flexible plugin architecture makes it easy to add new features (such as encryption, compression, different formats, etc.) to the filesystem. And so on.
Hans Reiser and his developers at Namesys are trying to change how people work with filesystems - and with computers as a whole. The underlying vision is one where the filesystem implements the entire namespace used by the system; everything truly is a file. In the Reiser view of the future, applications like relational database managers need not exist; such tasks will be handled in the filesystem itself.
What it comes down to is that reiser4 represents some of the most innovative work being done with filesystems for Linux - or for any other system. So one might well wonder why inclusion is proving to be such a challenge. Some of the reasons are straightforward: there were genuine issues with the code. The "files as directories" capability opened the door to trivial, user-initiated kernel deadlocks - a feature which can absolutely ruin those performance benchmarks. The multiplexed sys_reiser4() system call - to be used for managing transactions, among other things - is just the sort of call that the Linux developers are trying to get away from (and its use of an in-kernel command interpreter did not help). A number of other things needed to be fixed; the Namesys hackers have been working through the list, but a few items remain.
The real point, however, is that getting code into the kernel is an increasingly hard thing to do. In the early days of Linux, almost any code which made things work or added new features was welcome - we needed it all. In more recent times, it is often hard to argue that new features are truly needed, especially at the kernel level. So each new addition must be weighed against the costs that will be incurred when it is added.
The result is that the standards for new kernel code have gone up considerably over the years. Reiser4 has run into these standards, and objections have been raised to code which duplicates features found elsewhere in the kernel, is hard to read, violates the layering rules, has unclear locking schemes, or which uses obsolete interfaces. The point is that, in order to be merged, the reiser4 code must be understandable by people other than its original developers. As Alan Cox put it:
"What happened later on" is that the reiser3 developers moved on to reiser4; not only did they stop maintaining the code, but they actively opposed updates made to the code by other developers. At this point, reiser3 is almost entirely maintained by non-Namesys developers. In the future, the same thing may well happen with reiser4.
The crux is this: the Linux kernel has been around for 14 years, and is expected to last for quite a few more. The kernel hackers understand that, if they are insufficiently careful about what they merge now, they will have a big mess to deal with five years down the road. Many developers, working in all areas of the kernel, have had seemingly good code turned away because the development community was worried about maintaining the code in the future. The process is most frustrating for the people involved, but it is absolutely essential if we want to continue to use Linux into the future. To many, the difficulties encountered by reiser4 (and FUSE, and the realtime LSM, and class-based kernel resource management, and ...) represent the kernel development process at its worst, but the opposite is true.
That said, reiser4 has had a harder time and more microscopes applied to its
code than many other developments. Mr. Reiser's approach to community
relations, which strikes many as occasionally belligerent and paranoiac,
certainly has not helped here. This issue has been discussed often, but
there is another issue which deserves airing: some people are clearly
uncomfortable with the vision behind the ongoing Reiser filesystem effort.
It doesn't quite look like the Unix systems we grew up with. Linux is not
an experimental or research-oriented system, so the inclusion of radically
different ideas of how the system should work must be carefully
considered. But Linux must also evolve, or risk irrelevance in the
future. Hans Reiser's efforts to push that evolution are a good thing; the
community discourages such work at its peril. So perhaps the time has come
to let reiser4 in; the wider community can then get to work dealing with
any remaining issues.
| Index entries for this article | |
|---|---|
| Kernel | Development model |
| Kernel | Filesystems/Reiser4 |