Reiser4 and kernel inclusion

Reiser4 includes a "wandering log" mechanism provides journaling capability without the need for a separate journal.

So it was particularly distressing when some months ago, perhaps as much as a year (I can't remember exactly) Hans was going on (on lkml) about Reiser4 leaving ext3 "in the dust" and having the benchmarks to prove it (btw, I think that "in the dust" is probably a good place to start if you want to google for the thread) when former employee Nikita Danilov spoke up to remind Hans that he was the one who had conducted those benchmarks and that furthermore, when he went to Hans to show him how dismally Reiser4 performed compared to ext3 in some phases of the test, Hans told him to simply remove the results which were unfavorable to Reiser4 and publish the rest.

Hans admitted on the list that he had done so and stated that he would make a note on his site about the omitted results. To this day he has not done so.

He had some ideas at the time as to how to get around the performance problems, but his own employees were telling him (also on lkml) that his ideas would not work.

I try to keep all that in mind when trying to evaluate the veracity of Hans' statements.

If you're looking for faults with him it's shooting fish in a barrel. But so what. To misquote Al Davis, His ideas are going to take us to the next level, baby. It's going to be a royal pain in the ass, and it's the right thing to do.

As for the personnality of Hans Reiser, well, he is quite abrasive, it's a fact. So what ? He is not the only one, and he is not the most abrasive.

In other words, some of the kernel developers are giving reiser4 an extra hard time of it because Hans Reiser has angered them and this is how they can use their power to punish him. Is that what's happening?

Or is it that Hans's alleged belligerence and paranoia has somehow contributed to technical issues which need to be solved before reiser4 can be included?

I am in favor of its inclusion *AFTER* the very valid issues raised on lkml have been addressed. Just like *anything else* that goes into the kernel.

The problem is really that Hans didn't start by understanding how the division of labor among kernel subsystems worked and why it was set up that way, so the parts where he has really good ideas aren't the parts that are in a state suitable for submission, and so he doesn't have anything better to take up his attention than flaming people.

For example, does anyone use NTFS' multiple streams feature, except to hide malware? HFS+'s multiple streams just cause pain when e.g. backing a Mac up to a Linux server. Metadata indexing such as in BFS was nice, but insufficient -- we want full-text indexing now, and the kernel is no place for such complicated code. Extended metadata is a losing strategy anyway.

Reiser is supposedly fast, and so is ext2/3, but it doesn't matter. There is no universally fast filesystem; a speed gain for one task is often offset by a speed loss for another task. If you need speed, you need many fast spindles. The noatime mount option is good (that noatime is an option at all is another argument against features!). If you have a trustworthy UPS, you can consider the async option.

The thing to do, if you insist on having a filesystem at all, is to make it as simple and safe as possible, and to provide a mechanism for user code to be called when certain filesystem events happen -- push the complexity out to userland. Some Linux systems come with a daemon that monitors filesystem updates, so that it can keep its own data structures updated (e.g. a full-text index).

Even better, though, is to just get rid of filesystems. See EROS and Coyotos.

I'm not so much against ReiserFS per se, as I am against creeping featurism.

Andrew Morton recently suggested that number of major features lined up for the kernel have been slowing down. But instead of seeing this as a symptom of a release cycle speed that doesn't allow for big new features, he sees it as a sign that the kernel is nearly "finished", whatever that means.

The core developers see it as their job to put up barriers for new ideas, shouting down anything new or different. Only the elite are good enough to prove themselves and get the ultimate "mainline merge". Sure, it works, but it's a negative and destructive culture to be creating.

So now where is the direction for development coming from? The push for Reiser4's features have come from Hans Reiser himself, and through his costant dedication he might get a subset of it might be merged.. eventually. One person slogging away to make change. What is this? government bureaucracy or something? I thought this was meant to be a community.

Of course new features are going to slow down when the barriers to new feature inclusion are so high that you need to spend years working on something, and possibly get yourself into hundreds of thousands of dollars of debt, just to create a gift that is so easily wasted.

Features need to be brainstormed, pondered, considered, played with, listed, given scenarios to work through, and allowed to grow and develop. Not just constantly shouted down. There needs to be someone in charge of managing ideas and potential new features for the linux kernel, not only a hord of hackers who know better.

I'm not saying it's wrong to criticise an idea or a patch or whatever, and certainly Linux wouldn't what it is today without Linus taking the role of chief of "saying no" to patches. But where's the other side that makes new things? It rarely seems to come from within, and worse, is rarely encouraged.

</armchair developer rant>

Now for my proposed solutions:

* How about Linus starts a 2.7 branch to encourage some new major features. This would be concurrent with the current development style, but give a place for some major changes to simmer. And would encourage developers to think about major features again.

* Reiser4 folk and people looking for then next new thing start their own distribution that only runs with a Reiser4 fs, and makes its feature visible to users as much as possible, and exploits its features as much as possible. For example, having pretty displays of file metadata in Nautilus, and creating intuitive interfaces for opening folders that are also files, or having scripts that dont care if they create a lot of little files in a directory (when it makes sense to do so). Of course it's all just a simple matter of programming. (i.e. a lot of work), but would give interested users a way to use Reiser4 and explore its features, without needing mainline inclusion.

* Kernel development should try working on wikis more. In my experience, wikis allow ideas to grow and develop better than mailing lists, which are more geared towards people making points, and are so conducive to flamewars.

</armchair developer proposals>

Pengo.

http://www.economist.com/science/tq/displayStory.cfm?stor...

Hans Reiser is certainly right about the historical trend here.

In the Reiser view of the future, applications like relational database managers need not exist; such tasks will be handled in the filesystem itself.

This just shows why Reiser’s work will never fly. While he looks great in technical and managerial abilities, he (just like most people, including people commenting here like Wol) has got the fundamentals all wrong.

The relational model prescribes a far simpler, more powerful logical interface to data than the one proposed by Reiser. Just as most people, he has believed SQL vendors’ claim of being relational and thus has thrown out the concept without ever having understood it.

The situation here is somewhat similar to, but worse still than, the one in programming models: people bypass functional programming and formal methods because they think them too hard, without ever having ever tried; lack of understanding and familiarity in the beginning eventually makes for much more and worse work in the long run, and thus Java on Oracle instead of functional programming on a relational DBMS.

Choice divides a path of sanity.