fsync just once a second is a very bad idea. about buntdb HOT 4 CLOSED

Thanks for mentioning this. I agree that some more clarification can be made around this topic. I also look forward to providing optional fsync policies of Always, EverySecond, and Never.

Salvatore Sanfilippo talks about the same thing. http://redis.io/topics/persistence#how-durable-is-the-append-only-file

from buntdb.

I updated the README and added a SyncPolicy which can be set to Always for fsyncing after every write. b4e23eb

from buntdb.

Redis is awful database to learn from. Just keep it in mind. It did almost all wrong internally. Single thing it did well is user API.

You may batch and pipeline fsync requests:

• several request made within 1ms are batched, written and fsync request is sent. Batch waits on this particular fsync to return. (you may consider using Future: https://godoc.org/github.com/Workiva/go-datastructures/futures#Selectable )
• next batch will sent next fsync request without waiting for previous batch to return. Modern Linux systems performs well this way.

Combining batching with pipelining you may reach acceptable throughput without sacrificing durability.

Of course, it will not as fast as fsyncing once a second, and it will have large latency.

from buntdb.

Very helpful information. Thank you for sharing with me. I'm starting to lean towards setting the sync policy to Always by default. Then the user can choose what's best for their application, even turning it off altogether.

from buntdb.