Message-ID: <4D17EC27.4050808@ontolinux.com>
Date:	Mon, 27 Dec 2010 02:30:15 +0100
From:	Christian Stroetmann <stroetmann@...olinux.com>
To:	Ted Ts'o <tytso@....edu>
CC:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-ext4@...r.kernel.org,
	Olaf van der Spek <olafvdspek@...il.com>,
	Nick Piggin <npiggin@...il.com>
Subject: Re: Atomic non-durable file write API

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists