On Jan 4, 2009, at 4:11 PM, Geir Magnusson Jr. wrote:
On Jan 4, 2009, at 2:59 PM, Damien Katz wrote:
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.
Have you seen the correlation between the # of pirates and global
warming? :)
There may be correlation here between the Erlang update and
corruption, but I don't see the causality - fsync() on linux should
only get as far as the on-device buffering if it does write
buffering, whereas if the OS X docs are truthful, the F_FILESYNC
fcntl() pushs the bits to the rust on the platter. Maybe they fixed
something else in that erlang update, or maybe the universe is
smiling upon CouchDB users or ....
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.
I have an idea.... try it. I bet you can't get better than that
(6-8 inserts per second) on Mac OS X unless you have stupid-fast
disks (like maybe an SSD).
Even get a "back of the envelope" approx using time and curl - that
came in at the same rate as Ruby, JS and Java test programs.
Everyone who has tried my experiment on IRC has reported the same
numbers. I can get 6/sec on a laptop (2.5GHz core2 dual core MBP w/
4GB ram and a 7200rpm disk), and 8/sec on my desktop (a quad-core, 8
GB w/ raided 7200rpm disks, IIRC)
geir
Okay, very well. If you find evidence this is broken on Linux systems,
please file a bug.
-Damien
