Well, when I asked about the necessity for the then-current level of
commit-to-disk behavior, I got answers like :
On Jan 4, 2009, at 12:45 PM, Jan Lehnardt wrote:
On 4 Jan 2009, at 14:09, Geir Magnusson Jr. wrote:
2) Is anyone using CouchDB in a manner that really requires this
level of data security? I appreciate having the *option* to turn
on a mode like this, but I don't think I need it all the time. I
can use RAID systems that give me battery-backed cache, or I can
make the design decision that I am happy to lose X seconds of data
in a tradeoff (e.g. do the deep fnctl() every X seconds.....)
Everybody. CouchDB doesn't have an `off`-switch. You just terminate
the Erlang VM. Without this design, this wouldn't be possible. There
has been no discussion about optionally making different trade-offs
for speed and against data integrity, but this is not off-the-map.
So for something this fundamental and stated to be a necessity for
dealing w/ the Erlang VM, it seems odd that it would be prudent to do
a 180-turn and completely invert the behavior w/o any discussion...
I must be missing something.
geir
On Jan 5, 2009, at 4:16 AM, Sven Helmberger wrote:
Geir Magnusson Jr. schrieb:
Doesn't something like this at least warrant a "head up" kind of
mail to the dev list? How does it work? How can I control the
asynchronicity?
I just understood that as simply responding to the client before you
really have written everything to disk and queue the writes on the
server side to be actually written -- which is not something you need
control over.
Regards,
Sven Helmberger
