Abilio Marques wrote: > Hello, > > I've successfully ported a particular piece of software from multiple plain > files in disk to LMDB. There were multiple reasons to do so (i.e., > performance and > maintenance). > > The program is making individual calls to a storage API, that in turn creates > files or reads them (through a cache). There is no concept of transaction. For > performance and lifetime reasons, the original code avoids to perform a fsync > every time it writes to a file by queuing renames (for atomic writes) and > deletes, > which in turn are executed by a background thread after 2 seconds idling (or > a max of 15 sec after first write/delete). > > Replacing such a monster "files + cache" with LMDB was a breeze. I kept the > API intact, and to deal with the price of fsyncs, I thought of opening with > MDB_NOSYNC, and sync after 2 seconds of inactivity.
As documented, MDB_NOSYNC is only safe for power failure if the filesystem guarantees that it preserves the order of writes. Otherwise all bets are off. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
