couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Faster updates, optional ACID
Date Mon, 05 Jan 2009 19:51:55 GMT

On Jan 5, 2009, at 2:38 PM, Chris Anderson wrote:

> On Mon, Jan 5, 2009 at 11:32 AM, Damien Katz <damien@apache.org>  
> wrote:
>>>
>>> 1) delayed commit (what you did last night)
>>> 2) fsync() commit (what I suspect Couch did on and around 0.8)
>>> 3) optional F_FULLSYNC commit, on OS X and any other platform that
>>> provides this level of commit
>>>
>>
>> If necessary and possible, we'll patch the Erlang VM. But if a  
>> platform
>> doesn't support proper flushing, then it's not a platform that can  
>> support
>> an ACID database.
>>
>
> If I follow correctly, you're saying that on OS X, 2 == 1, so we use 3
> when we want to be ACID. On Linux, as far as we know, 2 will support
> ACID. There's only really two options, ACID commit, and delayed
> commit. It's up to CouchDB / Erlang / the OS to make sure that the
> ACID option isn't false advertising. Makes sense.

If fsync doesn't work on a platform (like previously on OS X), then  
neither the delayed commit or fully flushed commit can work.

The way the delayed commit works, the database on disk is never in an  
inconsistent state. The new data may be partially written and the  
header in memory points to it, but the header on disk still points to  
the old consistent data. So this new option isn't like OS X before the  
F_FULLFSYNC patch, because that could actually cause corruptions  
(header points to incomplete structures) and you'd lose previously  
committed data. This new patch might lose the last uncommitted writes  
if it crashes before the final flush, but the previously committed  
data is always consistent and instantly available, no fixup needed.

-Damien

>
>
>
>> Definitely, I think commit options should be settable per-database.  
>> But for
>> now I was just wanting to address the slowdown, especially for  
>> replication
>> and the tests, to keep everyone productive. More commit features  
>> and options
>> is lower priority work for now, I was just addresses the most serious
>> slowdown.
>
> The config system is so flexible and easy to hook into, that I'm not
> worried about adding these settings. Should be a breeze once the
> software itself is settled.
>
> +1 to the whole thing.
>
> -- 
> Chris Anderson
> http://jchris.mfdz.com


Mime
View raw message