Filesystem developer Hans Reiser cannot be accused of giving up quickly.
His current request
that the reiser4
filesystem be included in the 2.6.14 kernel has created a lengthy
discussion, but that's not where the story starts. In fact, Hans first asked that reiser4 be merged
in July - of 2003. For more than two years, Hans has repeated his request
and made changes in response to feedback from the kernel development
community. Yet reiser4 remains out of the mainline, and its chances of
getting into 2.6.14 appear small.
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:
It doesn't matter if reiser4 causes crashes. It matters that people
can fix them, that they are actively fixed and the code is
maintainable. It will have bugs, all complex code has bugs. Hans
team have demonstrated the ability to fix some of those bugs fast,
but we also all remember what happened with reiser3 later on
despite early fast fixing.
"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.
to post comments)