From: Theodore Tso <tytso@mit.edu>
To: Eric Hopper <hopper@omnifarious.org>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: Question about Reiser4
Date: Mon, 23 Apr 2007 18:56:41 -0400 [thread overview]
Message-ID: <20070423225640.GA1663@thunk.org> (raw)
In-Reply-To: <20070423135216.GA2744@omnifarious.org>
On Mon, Apr 23, 2007 at 06:52:16AM -0700, Eric Hopper wrote:
> Oh, two things really interest me about Reiser4. First, I despise
> having to care about how many tiny files I leave lying around when
> writing a program. Berkeley DB and its ilk are evil, evil programs that
> obscure data and make things harder. Secondly, the moves Reiser4 has
> made towards having actual transactions at the filesystem level also
> intrigue me.
>
> I want to use the filesystem as a DB. IMHO, there is no reason that
> filesystems shouldn't be a DB sans query language. If there were a more
> DB-like way to deal with filesystems, I think that it would be that much
> easier to make something that was a decent replacement for NFS and
> actually worked.
One of the big problems of using a filesystem as a DB is the system
call overheads. If you use huge numbers of tiny files, then each
attempt read an atom of information from the DB takes three system
calls --- an open(), read(), and close(), with all of the overheads in
terms of dentry and inode cache.
Hans of course had a solution to this problem --- namely the
sys_reiser4 system call, where you download a program to the kernel to
execute a open/read/close via a single system call, and which returns
the combined results to userspace. But now you have more complexity
since there is now a reseir4-specific interpreter embeddeed in the
kernel, the userspace application needs to write the equivalent of an
channel program such as what was found in an IBM/360 mainframe (need I
mention this can be a rich source of security bugs), and then the
userspace application *still* needs to parse the result returned by
the sys_reiser4() system call?
So it adds a huge amount of complexity, and at the end of the day,
given that you don't have the search capability, it is (a) less
functional, (b) more complexitated, and (c) probably less performant
than simply calling out to a database.
> Sadly, unless someone pays me to maintain it, I can't do the fork
> myself, and I likely wouldn't anyway as being a kernel hacker of
> something as important as a filesystem is a full-time job and I have
> other things that interest me a lot more.
Unfortunately, the way OSS works is that you either (a) have to do the
work yourself, (b) convince someone else to do the work, or (c)
convince someone that it's worth paying you to do it.
Personally, if I controlled large budget for Linux filesystem
development, I'd put a lot more money into something like Val's
chunkfs idea than resier4. Being able to have filesystems designed
for fast recovery given disks getting larger and larger (but not more
reliable), is a whole lot more improtant than trying to create an
alternate solution to an already solved problem --- namely that of a
database. When you consider that a similar idea, WinFS, was partially
responsible for delaying Vista by years due to the complexity of
shoving a database where it has no place being, it's another reason
why I personally think that chunkfs is a much more promising avenue
for future filesystem investment than reiserfs.
But hey, the advantage of Open Source is that if *you* want to work on
Reiser4, you're perfectly free to do so. My personal opinion is that
it'd be a waste of your time, but you're free to spend your time
whichever way that you want. What you don't get do is whine about how
other people get to spend *their* time, or *their* money.
- Ted
next prev parent reply other threads:[~2007-04-23 22:56 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-23 2:00 Question about Reiser4 Eric Hopper
2007-04-23 2:31 ` Lee Revell
2007-04-23 3:56 ` Rik van Riel
2007-04-23 3:56 ` William Heimbigner
2007-04-23 5:47 ` Rik van Riel
2007-04-23 5:57 ` William Heimbigner
2007-04-23 6:07 ` Rik van Riel
2007-04-23 6:14 ` William Heimbigner
2007-04-23 6:20 ` Rik van Riel
2007-04-23 6:42 ` William Heimbigner
2007-04-23 8:04 ` Andrew Morton
2007-04-23 11:31 ` l.genoni
2007-04-23 13:52 ` Eric Hopper
2007-04-23 17:40 ` Andrew Morton
2007-04-23 18:36 ` Miguel Ojeda
2007-04-23 19:05 ` Andi Kleen
2007-04-23 22:56 ` Theodore Tso [this message]
2007-04-23 23:53 ` H. Peter Anvin
2007-04-24 0:14 ` Neil Brown
2007-04-24 0:21 ` H. Peter Anvin
2007-04-24 13:30 ` Jan Engelhardt
2007-04-24 0:19 ` Theodore Tso
2007-04-24 0:31 ` H. Peter Anvin
2007-04-24 1:17 ` Theodore Tso
2007-04-24 11:15 ` Denis Vlasenko
2007-04-25 6:39 ` Eric M. Hopper
2007-04-25 14:45 ` lkml777
2007-04-23 6:14 ` Jeff Chua
[not found] <20070423111939.c876c9cc.akpm@linux-foundation.org>
2007-04-24 14:43 ` Edward Shishkin
2007-04-24 19:39 ` Andi Kleen
2007-04-25 14:35 ` Edward Shishkin
2007-04-25 14:49 ` Jeff Chua
2007-04-25 15:06 ` lkml777
2007-04-25 15:50 ` Jeff Chua
2007-04-26 5:05 ` lkml777
2007-04-26 6:49 ` Jeff Chua
2007-04-26 5:09 ` lkml777
2007-04-26 6:48 ` Jeff Chua
2007-04-26 8:18 ` Jeff Chua
2007-04-27 7:16 ` lkml777
2007-04-26 0:44 ` lkml777
2007-04-25 0:12 ` lkml777
2007-04-25 6:26 ` Eric M. Hopper
2007-04-25 15:03 ` Edward Shishkin
2007-04-26 7:47 ` lkml777
2007-04-26 7:54 ` lkml777
2007-05-02 2:39 ` lkml777
2007-05-02 4:53 ` lkml777
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=20070423225640.GA1663@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=hopper@omnifarious.org \
--cc=linux-kernel@vger.kernel.org \
/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