| |||||||||||||
Reiser4 and kernel inclusionReiser4 and kernel inclusionPosted Sep 22, 2005 15:20 UTC (Thu) by vonbrand (subscriber, #4458)In reply to: Reiser4 and kernel inclusion by NAR Parent article: Reiser4 and kernel inclusion
Right, the Database is in the filesystem has been tried numerous times. Wonder why none of them is still around...
(Log in to post comments)
Reiser4 and kernel inclusion Posted Sep 22, 2005 15:54 UTC (Thu) by zlynx (subscriber, #2285) [Link] 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.
Reiser4 and kernel inclusion Posted Sep 23, 2005 12:32 UTC (Fri) by NAR (subscriber, #1313) [Link] 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.
Reiser4 and kernel inclusion Posted Sep 23, 2005 14:11 UTC (Fri) by zlynx (subscriber, #2285) [Link] 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] 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 Xserverdo 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 (guest, #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,
Reiser4 and kernel inclusion Posted Sep 23, 2005 16:45 UTC (Fri) by IkeTo (subscriber, #2122) [Link] > "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 (guest, #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,
Reiser4 and kernel inclusion Posted Sep 23, 2005 11:28 UTC (Fri) by job (guest, #670) [Link] The file system *is* a database. It is a hierarchical database which maps keys to BLOBs, essentially, with some meta data on the side. There has been some evolution in the file system space during the last decade, but things move very slowly.
For example is it mainstream among Linux distributions to index the keys properly now which is a very database-ish thing to do (which reiserfs 3 pioneered in Linux by the way). Also the BeFS had some very interesting queries, which may be a niche market today but far from dead.
The next step would be to have a better interface for open queries that scales (perhaps inotify?) and extensible metadata with proper indexing. Reiserfs3 also has tail packing which is a very nice feature that I hope spreads to other file systems. Reiser4 is a very interesting next step, and I would be sad to see it vanish just because of implementation.
Reiser4 and kernel inclusion Posted Sep 29, 2005 7:43 UTC (Thu) by Wol (guest, #4433) [Link] Right, the Database is in the filesystem has been tried numerous times. Wonder why none of them is still around... Probably because people nowadays equate "database" with "relational database". Relational theory is a mathematical theory, and as such there is no evidence that it actually works in the real world. Occam's Razor says it doesn't .... The original razor (translated) is, I believe, "don't multiply entities unnecessarily". What is a relational database but "a maze of twisty little tables, all different" :-) A relational database is just too bloody complicated to be a good solution... Cheers,
|
|||||||||||||