From: "Nate Diller" <nate.diller@gmail.com>
To: "Marc Perkel" <marc@perkel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Visionary ideas for SQL file systems
Date: Wed, 14 Jun 2006 15:34:33 -0700 [thread overview]
Message-ID: <5c49b0ed0606141534o45c75699n490f4accbfee028d@mail.gmail.com> (raw)
In-Reply-To: <448F8F18.4030200@perkel.com>
On 6/13/06, Marc Perkel <marc@perkel.com> 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
prev parent reply other threads:[~2006-06-14 22:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-14 4:22 Marc Perkel
2006-06-14 7:49 ` Xavier Bestel
2006-06-14 9:47 ` Jan Engelhardt
2006-06-14 12:10 ` Michael Raskin
2006-06-14 13:29 ` Marc Perkel
2006-06-14 22:34 ` Nate Diller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c49b0ed0606141534o45c75699n490f4accbfee028d@mail.gmail.com \
--to=nate.diller@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marc@perkel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®