[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D18E94C.3080908@ontolinux.com>
Date: Mon, 27 Dec 2010 20:30:20 +0100
From: Christian Stroetmann <stroetmann@...olinux.com>
To: Olaf van der Spek <olafvdspek@...il.com>
CC: linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-ext4@...r.kernel.org, Ted Ts'o <tytso@....edu>,
Nick Piggin <npiggin@...il.com>
Subject: Re: Atomic non-durable file write API
On the 27.12.2010 20:07, Olaf van der Spek wrote:
> On Mon, Dec 27, 2010 at 4:30 PM, Christian Stroetmann
> <stroetmann@...olinux.com> wrote:
>>> Like I've said dozens of times, this is not about full DB functionality.
>>> Why do you keep making false analogies?
>> The analogy is not so wrong. The concepts atomicity and abort/rollback your
>> are talking about are also concepts of the field of database management
>> systems (DBMSs). And once you have established the Atomicity, which is the A
>> of the principle ACID of DBMSs, you have the basis for establishing the
>> rest, the CID.
>>
>> And you even went further into this DBMS direction by letting down the
>> requirement of non-durability.
> Of course the concepts are the same. That doesn't mean the analogy is valid.
Btw.: There is even no analogy: "The concepts are the same".
>>> Still waiting on any hint for why that performance loss would happen.
>> > From my point of view, the loss of performance depends on what is
>> benchmarked in which way.
> Maybe, but still no indication of why.
If you have a solution, then you really should show other persons the
working source code.
For me speaking: I like such technologies and I'm also interested in
your attempts.
> Olaf
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