<DKIM> Re: <DKIM> Re: <DKIM> [PATCH,review]: add lmdb folder backend
nicolas.s-dev at laposte.net
Mon Dec 19 23:18:25 GMT 2016
On Mon, Dec 19, 2016 at 09:37:36PM +0000, Luke Kenneth Casson Leighton wrote:
> ahh, that's the really cool part: that top-level b-tree, it's a
> single page (and all pages are aligned to match exactly with the OS's
> VM page size and boundary).
This makes me wonder if those databases can be moved to any other host.
If not, this limitation would need to be documented.
> if that one page (as an example) is not written out to disk properly
> on an fsync by the OS (or later as part of the ongoing flushing
> later), even on a powerloss or segfault, then you have much much
> bigger problems with the hardware and the OS than just having lmdb
> corrupt its data.
> if it *doesn't* get updated, then all that happens is that on restart,
> the application will discover that the entire database integrity is
> perfectly ffine... but that the history is back to whatever it was as
> if that top-level page wasn't written out.... i.e. the previous atomic
> write transaction.
However, I was talking about atomicity from the user POV. Atomicity to
ensure database safety does mean that the data integrity is honored for
the user (e.g., two writes should be atomic but only one gets written).
Since I've read a bit of the doc at
it appears that the backend provides a commit() method so I guess we're
> it's extremely powerful and i had no idea that shmem with
> copy-on-write could be used in such an amazing way. it took one
> reviewer a *YEAR* to fully understand lmdb.
More information about the OfflineIMAP-project