What you say is possible, but doesn't seem too likely as I don't ever
recall any report of a corrupt db on Linux, but before the F_FILESYNC
change in Erlang we would see reports of corruptions on OS X due to
power loss. Since the change, we've had no reports of corrupt
databases on OS X or Linux.
I don't think anyone else sees update performance that slow (I'm
assuming these are fairly small documents?), I'd guess there is
something particular about your setups. Since it involves update speed
it wouldn't be the javascript engine. It's possible it's the openssl
interface, I've seen instances of wacked openssl installs that slowed
down Erlang but didn't crash it.
-Damien
On Jan 4, 2009, at 1:35 PM, Geir Magnusson Jr. wrote:
I'm suspicious.
On an m1.small instance running 32-bit ubuntu 8 on ec2 running
trunk, I can get 85 inserts per second with the client running on
same slice, so no network hop. it's a single core instance, but I'm
not sure that would matter too much (i'll try later).
Now, this makes me wonder... the fsync() in linux isn't doing what
F_FILESYNC does in OS X presumably.... in which case what you think
is being done for you to work around the lack of an "off switch" in
the erlang VM isn't actually being done, and since no one seems to
have noticed, does it really matter? :)
To be fair, I'm going to try a better experiment on linux w/ more
cores and more clients...
geir
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.
Cheers
Jan
--
