On 6/13/06, Marc Perkel <[email protected]> wrote:
I'm going to throw this idea out there just to get people thinking.
There's nothing in reality that is like this except maybe some of the
ReiserFS ideas, but I want to take the idea farther. the idea is ......
recommend reading hans' future_vision.html paper at namesys.com, as
well as dominic's "FS design with the Be file system" which is a pdf
somewhere online now. some intense study of ADT's is also recommended
Why not put an SQL filesystem directly on a block devices where files
are really blobs within the filesystem and file names and file
attributes are all indexed data withing the SQL database. The operating
system will have SQL built in.
after going over the suggested reading above, you'll see why SQL is
less than ideal
Right now we have a variety of name spaces, file attributes, cluster
sises, inodes and other nasty stuff that are too exposed. Suppose that
you could add any fileds you want, any keys you want. Suppose that users
and groups could have any number of fields. Suppose you wanted to add
more levels like "managers" and some of the fancy Novell stuff. With a
database the user could create any kind of an interface to access files
that they want.
this goal is very worthwhile, but it's a lot harder than you imagine,
because of compatability, performance, security, and backwards
compatability.
<snip examples of nifty applications of the above>
So - this is totally outside the bix thinking but use you imagination
and envision what could be done if we lose the file system paradyme and
embrace the SQL based data paradhyme.
Will it be faster? Doing only what we are limited to today, no. Doing
what we would be able to do, yes. This is a radically new concept and
you should be very stoned to fully appreciate it. I just wanted to throw
lol
the idea out there so that people can start rolling it around and
thinking about it. It's an idea that is similar in some ways to the
/proc filesystem where things appear as files that aren't
others have suggested that all this belongs in user-space. hans and i
argue that point every once in a while still. i think it comes down
to -ENOPATCH
NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
