On the conviction of Hans Reiser

Hans Reiser was, of course, the designer (and, to an extent, implementer) of the reiserfs filesystem. When it was merged, reiserfs had the distinction of being the first journaling filesystem for Linux which was intended for general use; it also offered good performance in some situations, especially those involving lots of small files. Reiserfs saw a significant amount of use and was adopted by a handful of distributors. There are, doubtless, quite a few reiserfs deployments still operating out there.

Mr. Reiser's role in reiserfs development and maintenance ended some years ago, though. He stopped work on it when reiser4 development started, and even opposed the incorporation of improvements done by others. Reiserfs continues to be maintained independently of its creator, though there is not much interest in adding features to it at this point. Reiserfs is nearing the end of its run, and nothing which happened this week has changed that situation in any way.

There is more concern about what will happen with Reiser4, Mr. Reiser's next generation filesystem. Many reports have suggested that current events spell the end for this project, but it is worth taking a look at the longer history. Reiser4 is not exactly new; it was first posted in 2002. Mr. Reiser made an unsuccessful effort to get it merged for the 2.6.0 kernel, and frequently thereafter. He blamed commercial interests and politics for his failure in this regard, but the real situation is more straightforward than that.

Reiser4 tried to do a number of things very differently from other filesystems. It included some very non-POSIX semantics which raised red flags within the development community. There was a multipurpose reiser4() system call which implemented a wide range of features and included an in-kernel interpreter for a special language. There was a low-level plugin mechanism which raised concerns (not all justified) about varying on-disk formats and proprietary formats. Reiser4 did many things at the filesystem level that others thought should be done at the virtual filesystem level instead. The "files as directories" feature, beyond striking people as strange, opened up a wide range of trivial deadlock scenarios.

In summary, this code was nowhere near ready for inclusion into the mainline kernel. Kernel development projects which are done in isolation often encounter this kind of surprise when they are finally posted to the development community.

Over the next few years work on reiser4 continued. Many of the problems were solved by simply removing most of the features which made reiser4 unique, turning it into just another filesystem. Once you have just another filesystem, attention will turn to performance; in this case, many people found that they got benchmark results which differed from those posted by Mr. Reiser. Community interest in this filesystem fell over time, and the development rate fell as well. There was still work happening to prepare reiser4 for the mainline kernel when Mr. Reiser was arrested, but it was moving slowly.

Perhaps the biggest obstacle to the inclusion of reiser4, though, was the confrontational approach taken toward the rest of the community. When developers pointed out problems with reiser4, Mr. Reiser had a tendency to question their motives rather than pay attention to what they were saying. His interactions with the community were characterized by statements like:

A number of developers reached a point where they simply chose not to engage with him any more. By rejecting the development community, Mr. Reiser remained forever an outsider to it.

And that is why the practical effect of Mr. Reiser's conviction on the community will be relatively small, at least in the short term. As brilliant as he is, his effectiveness was limited by his disregard for the rest of the community and his certainty of always being right. He could have accomplished much more with a different approach.

That said, his loss is unfortunate. He did prove able, over a number of years, to raise funds for Linux filesystem work, and the community benefited from that work. Some of the reiser4 developers are still interested in working on that code, and they still submit patches. But now nobody is paying them to do that work, which puts the whole enterprise in danger. There are limits to how long reiser4 development can be carried forward as a labor of love.

The biggest loss, though, is elsewhere. More than anybody else, Mr. Reiser put a lot of thought into what our systems should look like in the future. He saw capable filesystems as the way to make our systems far more powerful than they are now. In a world where the filesystem was the only namespace of any significance on the system, all objects would be equal and the number of potential connections between them would explode. His long-term goal was not (just) better benchmarks; it was to create a filesystem which could serve as this all-encompassing namespace. It was a radical idea, and, perhaps, impractical. But our future comes from ideas like that.

After a few relatively quiet years, there is now a flurry of activity around Linux filesystems. The challenges in this area are large, but we have many highly capable developers working on the problem and there can be no real doubt that Linux filesystems will continue to be among the best available anywhere. But that development community has lost a voice which, for all its faults, had some unique and innovative things to say, and we are all poorer for it.