fsync just once a second is a very bad idea.

[funny-falcon]

You should at least mention in a README, that user can loose whole second of changes.

[tidwall]

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

[tidwall]

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

[funny-falcon]

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.

[tidwall]

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.