Subject: Re: [boost] NuDB: A fast key/value insert-only database for SSD drives in C++11
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-29 13:36:08
Niall Douglas wrote:
> Because a proper implementation of durability should be able to use no
> fsync and no O_SYNC at all. In that case, you get "late durability" where
> minutes of recent writes get lost after power loss. For users where that
> is unacceptable, O_SYNC should be turned on and you now have "early
> durability" where only seconds may be lost.
No such thing.
"The durability property ensures that once a transaction has been committed,
it will remain so, even in the event of power loss, crashes, or errors. In a
relational database, for instance, once a group of SQL statements execute,
the results need to be stored permanently (even if the database crashes
If you lose writes, it's not Durable, just Consistent.
The page you linked, https://www.sqlite.org/howtocorrupt.html, says
"Actually, if one is only concerned with atomic and consistent writes and is
willing to forego durable writes, the sync operation does not need to wait
until the content is completely stored on persistent media. Instead, the
sync operation can be thought of as an I/O barrier. As long as all writes
that occur before the sync are completed before any write that happens after
the sync, no database corruption will occur. If sync is operating as an I/O
barrier and not as a true sync, then a power failure or system crash might
cause one or more previously committed transactions to roll back (in
violation of the "durable" property of "ACID") but the database will at
least continue to be consistent, and that is what most people care about."