mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®