The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: reiser4?
by Pat on Wednesday 23/Feb/2005, @10:52
|
i think kernel devs wants to implement some of reiser4 unique functionalities into the kernel vfs so that other fs can use them and people won't be forced to use reiser4 but that ain't gonna happen anytime soon so I guess we have to wait. I wonder if we'll get it before winfs :) (the real winfs, not the one that will come next year with longhorn).
|
[
Reply To This | View ]
|
Re: reiser4?
by Aaron J. Seigo on Wednesday 23/Feb/2005, @13:24
|
> but would it make sense to create a reiser4 plugin to be used with your ideas
seeing as our time is not exactly limitless, i don't think doing two implementations with different storage designs is realistic, especially when very, very few people have the target data storage mechanism (reiser 4 file system) available to them. this is meant to be a practical project rather than a research topic.
> One could argue that this is where the information belongs: in the filesystem
yes, that's a viable argument given that the information you are indexing/linking exists in the filesystem in the first place. this assumption isn't universally true, however. not only is a lot of our data dynamically generated on demand these days, there's also a lot of data that is implied by our usage forming context that isn't a "document" or even necessarily very suitable for storage as a "file" on disk.
trivial example: how would you store a personal annotation of a web page in a filesystem based approach?
if we wish to more than just index and search local data, it becomes apparent that the file system is not the catch-all locus of our information anymore.
|
[
Reply To This | View ]
|
Re: reiser4?
by me on Wednesday 23/Feb/2005, @14:04
|
well, I'd probably store all annotations in C:\Progra~1\Common~1\Annota~1\HSDS6SB.TMP\ddf7d6s7.txt
I guess you're right :)
|
[
Reply To This | View ]
|
Re: reiser4?
by Simon Edwards on Wednesday 23/Feb/2005, @14:15
|
> trivial example: how would you store a personal annotation of a web
> page in a filesystem based approach?
The direction that Reiser is heading is towards a general filesystem/retrival system. Kind of a mix of a traditional filesystem plus a database, while being very flexible and 'plastic' (i.e. you wouldn't have to define a fixed schema before you could use it). Searching using partial chunks of info being a big part it. Basically you could build and search almost arbitrary data-structures (on disk). A traditional Unix style filesystem is just one thing that you could make using this kind of system, but much more would be possible.
Read, (and try to get your head around, it's hard!), the Future Vision paper at:
http://www.namesys.com/
--
Simon
|
[
Reply To This | View ]
|
Re: reiser4?
by Aaron J. Seigo on Wednesday 23/Feb/2005, @15:35
|
> The direction that Reiser is heading is towards a general
> filesystem/retrival system
yes, it's a very interesting and ambitious goal, one Oracle failed at in the 90s, though for market reasons rather than technical ones.
> Basically you could build and search almost arbitrary
> data-structures (on disk)
of course, and we're using an RDBMS to do exactly that at the moment. the reason that a file system doesn't offer anything (featurewise) above what the RDBMS does to make it more attractive is that not everything in the necessary "arbitrary data structures" refer/link to things that are local or even storable (e.g. time).
it's much more practical and reasonable to require people to installed 10MB of software that provides a database engine than it is to require them to reformat their disks and migrate all their data over. Reiser isn't even available for all the platforms KDE runs on. this removes it as a potential target for a practical tool, though it would make a really cool target for a research project.
i do think that applications will drive the success of Reiser4, however. and once we have tools such as what we are building, i wouldn't be surprised if someone worked the storage layer to oprtionally use Reiser4 to produce something smaller and more performant. at that point there's a real motivator to use these kinds of file systems that goes beyond the theoretical, at which point they become interesting from the point of view of "off the shelf" software users and manufacturers.
> Read, (and try to get your head around, it's hard!),
> the Future Vision paper at:
i have =) fun stuff... i've been watching Reiser's project for some years now with great interest.
|
[
Reply To This | View ]
|
Re: reiser4?
by David Neeley on Saturday 28/Oct/2006, @14:00
|
Frankly, I believe that SQL databases in general may not be the best solution for this problem.
Some years ago, I was one of the investigators into a potential application in which we benchmarked various database solutions. The "post-relational" databases of which the old Pick system was progenitor had performance many times that of the relational ones.
In case you are unaware of it, these databases comply with all but one of the Codd and Date's Rules of Normalization--the first, that every item must be "unique and atomic." In other words, a single record could store an entire table.
Consider the common introduction to relational databases in which a video rental store is used. One table contains the individual customer records, with a unique customer number. Another table contains the rental records, with one column containing the customer ID numbers. To get a look at rental history for a given customer, then, a join must be performed in which the rental table is searched with each rental by the given customer's ID being extracted to build the list.
In a Pick-style database, the individual rental info can be stored directly int he customer table. Extracting rental info merely means looking up that customer record and viewing the ever-expanding rental list. No joins, far less memory, and much more speed!
Another possibility might be a datastore similar to the "Titanium" database of Micro Data Base Systems. In that one, many-to-many relations can be directly mapped as selected by the programmer. This results in a well-written program having even more performance yet.
In our tests, the Pick style database ran about 25 times faster than the then-current SQL databases; the Titanium engine about 40 times faster and with much lower system overhead.
In short, the only advantage I see for an SQL system is the large number of tools available for them.
David
|
[
Reply To This | View ]
|
|
Re: reiser4?
by Evan "JabberWokky" E. on Wednesday 23/Feb/2005, @14:12
|
:: One could argue that this is where the information belongs: in the filesystem.
The problem is, KDE targets the nebulous "Unix" as a goal. POSIX does not define much (are ACLs even defined as a standard, or are they an optional part of the standard?).
:: IIRC, Hans Reiser said that whenever you use a database, its because of the shortcomings of your filesystem, and the now-released reiser4 is supposed to fix that.
I agree so wholeheartedly it is difficult to express with words. I think a rich filesystem that is used by apps is as revolutionary as the desktop metaphor. But I also think that KDE is right not to make such a fundamental requirement. As an *optional* way of storing data, on the other hand...
Not to mention that a rich filesystem plus an advanced code rights system (a la jail) will result in a very secure, powerful and stable system - far more abuse tolerant and flexible than has ever been commonly available ("Open all the attachments you want - they run fine, anything they change rolls back, and they can't send Spam").
|
[
Reply To This | View ]
|
Re: reiser4?
by Aaron J. Seigo on Wednesday 23/Feb/2005, @15:44
|
> I think a rich filesystem that is used by apps
you hit the nail on the head: it has to be used by applications. if no applications use it, it's a theoretically cool idea with no real world benefits and becomes an unimportant interesting footnote in computing history.
this is why instead of targeting a unique storage system or creating one application/tool, we're creating a system that will allow any (and hopefully as close to "all" as possible) application to easily take advantage of these paradigms.
the location of the storage, filesystem or database or clay tablet, is an implementation detail with implications for performance and ease of implementation only. it's the application APIs that matter, and which are also missing. to analogize, Reiser and RDBMS's are like X Window: low level technologies that provides a means to accomplish the task (with varying degrees of success); things like what this interview is about are like Qt: a layer that makes application development leveraging the possibilities of the platforms possible.
innovation is not just the creation of a new idea, it's the implementation of that new idea in the marketplace.
|
[
Reply To This | View ]
|
|
Re: reiser4?
by uddw on Wednesday 23/Feb/2005, @14:12
|
Reiser4 as is won't fix a lot, except for more efficient storage of small files maybe. If you want to add a plugin for reiser4 you have to recompile your kernel. If you want other people to use it, you have to distribute a kernel patch. If you want to reach a broad audience in finite time you better put another layer on top of the FS to get things done.
I have started playing with reiser4 a while ago to write a plugin to enumerate changed files fast and reliably. But even if I find the time to get it done some day, it would still be hard to make people use it, at least with reiser4's notion of a plugin. If you want to introduce features which completely redefine a filesystem.. what can I say.. good luck?
|
[
Reply To This | View ]
|
Re: reiser4?
by superstoned on Wednesday 23/Feb/2005, @14:40
|
but if this was an option in KDE 4.0, the Gentoo guys will start using and testing it, then Suse and Lindows (ReiserFS4 sponsors) will test and maybe start using it, and others will follow...
thanx to the gentoo users we don't have much to do with the chicken-and-egg problem, they love new things (me as debian user does so, too, but its easier with gentoo to try them).
|
[
Reply To This | View ]
|
Re: reiser4?
by me on Wednesday 23/Feb/2005, @14:59
|
oh...interesting!
I'd like to store thousands of big images (between 10 and 200mb a piece) and need to be notified when they are changed...
Does your plugin have a webpage? I've been looking for something like that, and I've grown frustrated with the available solutions (fam, enhanced dnotify and even www.dazuko.org suck), so I'd like to know more...
Is reiser4 stable?
|
[
Reply To This | View ]
|
Re: reiser4?
by wilbert on Wednesday 23/Feb/2005, @15:48
|
> Is reiser4 stable?
According to www.namesys.com/v4/v4.html: "We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3." (as of 29 dec 2004).
So may be not yet, but testing will definitely be very, very interesting!
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
