Reiser4 and kernel inclusion

Posted Sep 22, 2005 15:54 UTC (Thu) by zlynx (guest, #2285)
In reply to: Reiser4 and kernel inclusion by vonbrand
Parent article: Reiser4 and kernel inclusion

How many times did Edison try to build a lightbulb?

Just because it hasn't worked before does not mean it won't work now or will never work in the future. It's important to learn from past mistakes, but the key word there is "learn." And then try it again.

to post comments

Reiser4 and kernel inclusion

Posted Sep 23, 2005 12:32 UTC (Fri) by NAR (subscriber, #1313) [Link] (7 responses)

How many times did Edison try to build a lightbulb?

Your analogy is wrong: "database in a file" is not a question of "can be done" or "can't be done". It has been done already at least 20 years ago and there are at least two implementations (VMS filesystem and Berkley DB), so there's nothing new with that. The real question is that should this be implemented in the kernel or in user space.

As I mentioned, the VMS filesystem has a feature like this. One of the recurring problem was that users backuped their MAIL.MAI files (the equivalent to /var/mail/<username>) via FTP to an another computer. Then when they restored the file, they saw that they lost their mail, because this MAIL.MAI file is a "database in file" and its structure is stored in the filesystem, in attributes. Of course, when the file was restored via FTP, the FTP server had no idea that this file should have any special attributes, so the file was created as a binary stream, instead of the special indexed format.

The UNIX filesystem has been designed and used for 35 years with the basic concept that a file is just a sequence of bytes. I'm afraid there are a lot of applications that depend on this fact implicitly and we could be in for some nasty surprises like the above mentioned scenario if this assumption is changed. My other problem with the "database in file" concept has been addressed elsewhere in this thread - code of this complexity shall be done in user space, not kernel space. It's easier to debug and if it crashes, it doesn't bring down the whole computer.

Bye,NAR

Reiser4 and kernel inclusion

Posted Sep 23, 2005 14:11 UTC (Fri) by zlynx (guest, #2285) [Link] (3 responses)

Apparently my analogy is just about perfect. Edison's lightbulb attempts didn't all simply fail to work. Some were too dim. Some burned out too quickly.

Problems appear and are fixed, until it works. You demonstrated one problem with database filesystems. Do you think that no one else has noticed that problem or thought of ways to fix it? No so!

Are you aware that the "should be done in userspace" argument is exactly why Linux was supposed to fail? It isn't a microkernel. Microkernels were supposed to be the greatest thing ever. Well, they aren't. The performance penalties for all that protection are too great.

Reiser4 and kernel inclusion

Posted Sep 23, 2005 14:46 UTC (Fri) by dvdeug (subscriber, #10998) [Link] (1 responses)

What should be done in user space is not simply a microkernel/normal-Unix kernel question, though. Every new feature is a question of whether it should be done in user space. Should a kernel handle video or leave it to user space? NT handles it in kernel, a much criticised decision. Linux offers a kernel-space implementation and a more powerful user-space implementation. Should emulation be done in kernel? Floating point emulation and supporting instructions from newer CPUs have been contested, but I think both have gone into released kernels. Should the kernel include a JVM? If not, should it continue supporting OSF executables on Alpha and x86 executables on AMD-64?

User-space or not is just not a question that should be answered with a knee-jerk response.

Reiser4 and kernel inclusion

Posted Sep 30, 2005 11:09 UTC (Fri) by forthy (guest, #1525) [Link]

For the video question: I think yes, it is a mistake to have the Xserver
do the card settings. Really. The Xserver should have exposed interfaces
to the card, and the kernel should know about the state, so that switching
VTs, resetting state after X crash or suspend will work.

For the drawing commands itself, something like the DRM module should be
used for 2D drawing, too.

Reiser4 and kernel inclusion

Posted Sep 29, 2005 7:46 UTC (Thu) by Wol (subscriber, #4433) [Link]

Even better - Edison finally fixed his problems by ditching his ideas and "borrowing" someone else's.

I think you'll find that the lightbulb, as finally produced by Edison, is a pretty close match to the lightbulb as patented by Joseph Swan. Oh - and that patent is dated the same or earlier than Edison's patents.

Cheers,
Wol

Reiser4 and kernel inclusion

Posted Sep 23, 2005 16:45 UTC (Fri) by IkeTo (subscriber, #2122) [Link] (1 responses)

> "database in a file" is not a question of "can be done" or "can't
> be done". It has been done already at least 20 years ago and there
> are at least two implementations

Um... I might be wrong, but I really think that "database in a file" isn't quite what ReiserFS achieves. Instead, what it achieved is "filesystem in a database". The whole filesystem is implemented by using database technologies that simply holds a single huge B+-tree, with journaling features and such. And the database is being backed by a raw block device. Because it is "a filesystem in a database", of course it has all the database features. It is just the question of whether it exposes the filesystem features of itself into the user space (ReiserFS 4) or not (ReiserFS 3).

Reiser4 and kernel inclusion

Posted Sep 23, 2005 19:13 UTC (Fri) by corbet (editor, #1) [Link]

In fact, "database in a file" is far removed indeed from what reiser4 is trying to do; comparisons with VMS are misplaced here. I suggest a read through the files on namesys.com to get an understanding of the ideas and vision behind reiser4. It will not be a quick read, and you have to deal with some of the stranger artwork I've ever seen in technical material, but it can be worth the effort regardless.

Reiser4 and kernel inclusion

Posted Sep 29, 2005 7:38 UTC (Thu) by Wol (subscriber, #4433) [Link]

At least 20 years ago?

Make that 40. Pick was born in 1967. Oh - and it's still around. It powers some of the biggest data warehouses in the world - far bigger than relational can handle.

Cheers,
Wol