Reiser4 and kernel inclusion [LWN.net]

Reiser4 and kernel inclusion

Posted Sep 22, 2005 17:47 UTC (Thu) by iabervon (subscriber, #722)
Parent article: Reiser4 and kernel inclusion

I think the real issue is that Hans is trying to write a new filesystem to revolutionize how we use files, but that just isn't exclusively the jurisdiction of a filesystem. In the Linux scheme, there is a restricted set of things that the filesystem does, and then there are other things that get done by the VFS. All of the really interesting stuff that Hans is doing belongs in the VFS, and shouldn't care too much about the filesystem in use. It would be nice to cat a file that's inside a tar file, but if that's done in a filesystem, you'll be able to do it on your hard drive, but doing it on a CD or a ramdisk won't work. Obviously, this is going to confuse users, who don't expect ramdisks to work differently from hard drives.

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.

(Log in to post comments)

Reiser4 and kernel inclusion

Posted Sep 22, 2005 19:30 UTC (Thu) by cventers (subscriber, #31465) [Link]

I'm a merge-Reiser4 supporter, and I'm not sure that your comment implies
your opinion on the issue this reply addresses, but "business interests"
do not belong in the Linux kernel.

Reiser4 and kernel inclusion

Posted Sep 22, 2005 22:25 UTC (Thu) by sbergman27 (guest, #10767) [Link]

I've expressed my opinion elsewhere in this thread. Here I am just stating a fact. Namesys has an interest in seeing that Reiser4 is the only filesystem with the additional features. Namesys also has a business interest in being the sole entity up to the task of supporting and extending Reiser4. Remember, they make their money from supporting and extending their code privately via paid contract. And while there is nothing wrong with that, one must keep in mind that Namesys' interests do not necessarily coincide with that of the rest of the community.

That is the reason Namesys is so resistant to the fixes that the other kernel developers have proposed. Hans' bad attitude is just a secondary effect and has diverted attention from the real issues.

Bottom line: I am not familiar enough with Christoph Hellwig's reputation to comment. However, I do trust Andrew Morton and Alan Cox to remain level headed and act in the best long term interests of the project. I trust them not to get carried away by Namesys' extensive hype. Likewise, I trust them not to speak against the merging of a patch simply out of spite.

BTW, if people want to use reiser4 without having to mess with the external patch, I'm pretty sure that the latest SUSE versions include it. Which is the way it should be. The vendors are free to add whatever feature patches they want; their trees are short-term. The vanilla kernel is all about long-term maintainability. Linux's future depends on it.

Reiser4 and kernel inclusion

Posted Sep 25, 2005 15:36 UTC (Sun) by IkeTo (subscriber, #2122) [Link]

> Namesys has a business interest in keeping the new features
> exclusive to its own filesystem.

Um... does the developers of the Internet (or actually, ARPANET) has any "business interest" in keeping the new features they design exclusive to the Internet? It seems to me that much of namesys funding comes from the same source as the initial development of the Internet (The Defense Advanced Research Projects Agency)...

Reiser4 and kernel inclusion

Posted Sep 24, 2005 18:01 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

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

He understood. He was trying to balance a grand vision with practicality. He has said he thinks his work should replace the VFS layer; i.e. he doesn't think it belongs in a normal filesystem driver. But he figured it would be easier to ship separately, and get included, as a loadable kernel module. I think Reiser4 would look a lot different if Hans Reiser owned the Linux kernel.

Moot point - he doesn't.

Posted Sep 27, 2005 2:49 UTC (Tue) by kirkengaard (subscriber, #15022) [Link]

And it's so good that he doesn't, and indeed, that no-one/everyone owns the linux kernel, and that it is dedicated to reproducing POSIX-standard functionality. See the Massachusetts OpenDocument debate for one example of why standardized functionality is ultimately optimal, and manufacturer-specific, non-standard implementations are less than optimal, even if they provide useful functionality. Grand visions are nice, but world-reproducible, world-repeatable, world-implementable specifications win. Hans didn't create an open specification, nor did he create a systematic approach to anything above filesystem data management. Look at his documentation. He starts, not with Linux integration at all, but with "What is a file?". His grand vision is generated a priori, ex nihil. He picks Linux as the recipient of his gift by default. His other options are Microsoft or the graveyard of niche OSes. He is doomed to see his beautiful whole-cloth implementations broken down into usable functions and adapted for use by people who don't have his ends in mind (with the possible exception of whatever DARPA uses it for). It's the commoditization problem.

Moot point - he doesn't.

Posted Sep 27, 2005 14:49 UTC (Tue) by IkeTo (subscriber, #2122) [Link]

Standardized functionalities might be "ultimately" optimal, but there are many points in the time when we haven't reach that "ultimate" state. At such times, standardization does far more bad than good.

Standardization requires that there is a group of people who are enthusiastic about the field, knowledgable with the field, and have implementation experience with the field. Without that, it is moot to even talk about standardization. Given that "viewing a filesystem as a file and directory at the same time, and nothing else, in order to implement a superset of POSIX functionality" is such a new vision, I don't think it to be a candidate for standardization or formal specification. At times, it is best to have no specification and no standards to obstruct experiments and developments.