<DKIM> Re: <DKIM> Re: <DKIM> [PATCH, review]: add lmdb folder backend

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Mon, Dec 19, 2016 at 11:18 PM, Nicolas Sebrecht
<nicolas.s-dev at laposte.net> wrote:
> 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.

 interesting question!  let me just bcc howard.  howard what happens
if you move an lmdb to another host with a totally different page
size?

> If not, this limitation would need to be documented.

 ack

>>  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.
>
> Sounds great.
>
> However, I was talking about atomicity from the user POV.

 oh - yes.  sorry, i was going into techie details.

> 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).

 yes absolutely.  single atomic writers.... but writers do *not* block
any read transactions.

> Since I've read a bit of the doc at
>
>   https://lmdb.readthedocs.io/en/release/#threads
>
> it appears that the backend provides a commit() method so I guess we're
> fine.

 yes.

l.