From: Christian Stroetmann <stroetmann@ontolinux.com>
To: Ted Ts'o <tytso@mit.edu>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4@vger.kernel.org,
Olaf van der Spek <olafvdspek@gmail.com>,
Nick Piggin <npiggin@gmail.com>
Subject: Re: Atomic non-durable file write API
Date: Mon, 27 Dec 2010 02:30:15 +0100 [thread overview]
Message-ID: <4D17EC27.4050808@ontolinux.com> (raw)
In-Reply-To: <20101227010434.GG2595@thunk.org>
On 27.12.2010 02:04, Ted Ts'o wrote:
> On Mon, Dec 27, 2010 at 01:30:05AM +0100, Christian Stroetmann wrote:
>> An FS could easily have the rest of the functions of a database
>> management system (DBMS) as an FSDB, a hybrid if you wish. An
>> example for such a hybrid is the ext2/3-sqlite FS...
> What are you talking about? If you mean creating a sqlite database on
> top of an existing file system, sure that works fine.
No, I don't mean this.
> That's the
> right solution. But if you mean trying to access sqllite via a
> file-system interface (i.e., via FUSE),
No, I don't mean this. I mean taking out the FUSE and do it directly.
> I suspect the result will be a
> disaster, precisely because the file system API isn't expressive
> enough to handle database functionality, and so the result ends up
> being a performance disaster.
Three times wrong:
Firstly, the result won't be a disaster.
Secondly, I already said in the e-mail before that file system API will
be extended by this additional database functionality, which is just
only a little architectural problem.
Thirdly, it won't end up in a performance disaster.
> So the answer is "use a database, using
> a database API, if you have database requirements".
No, I won't.
>> Furthermore, the performance of Oracle's solutions was and still is
>> so low, because they have a file system as a database that is
>> managed by a DBMS as a file that again is stored in an FS. Can you
>> see now what does the loss of performance?
> It was a disaster from a performance perspective even if the database
> was run on top of a raw block device....
Yes, for sure. So what?
>> And Oracle fears FSs like R4 that have database(-like)
>> functionalities, so it took those technical features of R4 for the
>> BTRFS, which they thought could stop its show.
>> And also, Oracle has started some months ago again to promote its FS
>> in a DB in an FS concept.
> I've never heard of the R4 file system, and apparently Google hasn't
> either. But if you think BTRFS is a database, you're fooling
> yourself. There's a lot more to a database than just using a b-tree.
I'm sorry, because I was really thinking that you do know that R4 is
used as the short term for the file system Reiser4.
And no, I'm not fooling, because I don't think that BTRFS is a
database. I only said that Oracle took technical parts of Reiser4 like a
b-tree datastructure and some other parts as a show stopper.
>> So, there must be something that is highly interesting with the idea
>> to use an FS as DBMS, not only for Oracle, but at least for the four
>> largest software companies.
> No, I think you're just utterly confused from a technical perspective.
No, I'm not utterly confused from a technical perspective. You really
have a wrong impression.
And if you read above again, then you will see that I already said that
Oracle has started once again the promotion of its concept with an FS in
a DB in an FS (this thing that you described as a performance disaster
even running on a raw block device). Do you claim that Oracle doesn't do
this?
I'm sorry, but I do believe Oracle, Microsoft and Apple more than you.
> - Ted
>
Christian Stroetmann
next prev parent reply other threads:[~2010-12-27 1:30 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTing7+SK+pavFehR4AGDbRRfFwvvzNxgWQ3zRp+O@mail.gmail.com>
2010-12-09 12:03 ` Atomic non-durable file write API Olaf van der Spek
2010-12-16 12:22 ` Olaf van der Spek
2010-12-16 20:11 ` Ric Wheeler
2010-12-18 22:15 ` Calvin Walton
2010-12-19 16:39 ` Olaf van der Spek
2010-12-23 15:49 ` Olaf van der Spek
2010-12-23 21:51 ` Neil Brown
2010-12-23 22:22 ` Ted Ts'o
2010-12-24 0:30 ` Christian Stroetmann
2010-12-24 0:48 ` Ted Ts'o
2010-12-24 1:00 ` Christian Stroetmann
2010-12-24 9:51 ` Ted Ts'o
2010-12-24 11:14 ` Olaf van der Spek
2010-12-24 11:25 ` Christian Stroetmann
2010-12-25 3:15 ` Ted Ts'o
2010-12-25 10:41 ` Olaf van der Spek
2010-12-25 11:33 ` Nick Piggin
2010-12-25 15:24 ` Olaf van der Spek
2010-12-25 17:25 ` Nick Piggin
2010-12-26 15:08 ` Olaf van der Spek
2010-12-26 15:55 ` Boaz Harrosh
2010-12-26 16:02 ` Olaf van der Spek
2010-12-26 16:27 ` Boaz Harrosh
2010-12-26 18:26 ` Olaf van der Spek
2010-12-26 16:43 ` Nick Piggin
2010-12-26 18:51 ` Olaf van der Spek
2010-12-26 22:10 ` Ted Ts'o
2010-12-27 0:30 ` Christian Stroetmann
2010-12-27 1:04 ` Ted Ts'o
2010-12-27 1:30 ` Christian Stroetmann [this message]
2010-12-27 2:53 ` Ted Ts'o
2010-12-27 10:21 ` Olaf van der Spek
2010-12-27 11:07 ` Marco Stornelli
2010-12-27 15:30 ` Christian Stroetmann
2010-12-27 19:07 ` Olaf van der Spek
2010-12-27 19:30 ` Christian Stroetmann
2010-12-28 17:22 ` Olaf van der Spek
2010-12-28 20:59 ` Neil Brown
2010-12-28 22:00 ` Greg Freemyer
2010-12-28 22:06 ` Olaf van der Spek
2010-12-28 22:15 ` Greg Freemyer
2010-12-28 22:28 ` Olaf van der Spek
2010-12-28 22:35 ` Neil Brown
2010-12-29 11:05 ` Dave Chinner
2010-12-28 22:10 ` Olaf van der Spek
2010-12-28 22:31 ` Neil Brown
2010-12-28 22:54 ` Olaf van der Spek
2010-12-28 23:42 ` Ted Ts'o
2010-12-29 9:09 ` Olaf van der Spek
2010-12-29 15:30 ` Christian Stroetmann
2010-12-29 15:41 ` Olaf van der Spek
2010-12-29 16:30 ` Christian Stroetmann
2010-12-29 17:14 ` Olaf van der Spek
2010-12-30 0:50 ` Neil Brown
2011-01-07 14:23 ` Olaf van der Spek
2010-12-27 4:12 ` Nick Piggin
2010-12-27 11:48 ` Olaf van der Spek
2010-12-27 12:43 ` Olaf van der Spek
2010-12-28 0:45 ` Ted Ts'o
2010-12-24 11:21 ` Christian Stroetmann
2010-12-24 11:17 ` Olaf van der Spek
2010-12-24 11:29 ` Christian Stroetmann
2010-12-24 11:30 ` Olaf van der Spek
2010-12-25 21:40 ` Neil Brown
2010-12-23 22:43 ` Dave Chinner
2010-12-23 22:47 ` Ted Ts'o
2010-12-26 9:59 ` Amir Goldstein
2010-12-26 15:23 ` Olaf van der Spek
2010-12-26 16:52 ` Nick Piggin
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=4D17EC27.4050808@ontolinux.com \
--to=stroetmann@ontolinux.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=olafvdspek@gmail.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).