...

...

Alberto Mardegan mardy@users.sourceforge.net schrieb am 06.04.2020 um 08:44

in Nachricht <10444_1586183585_5E8B3DA1_10444_128_1_5863f87e-d26b-2943-9302-bf5bfc270e71@user .sourceforge.net>:

Hi all! I'm trying to understand the impact that a LDMB database will have on the flash wear of an embedded device.

In order to minimize disk writes, I'm keeping a DB open all the time, and I'd like to have the changes written into the physical storage only when mdb_env_sync() is called (near the end of my process lifetime). I'm opening the DB with the MDB_NOSYNC | MDB_WRITEMAP | MDB_NOMETASYNC flags, and if I strace the executable I see that lmdb behaves as expected: no writes happen until I call mdb_env_sync().

However, the writes end up to the physical storage anyway, because the kernel reserves the right of flushing changes of an mmap'ed file to disk at any time (as per the documentation of MAP_SHARED). I don't exactly know if this happens because some other process is calling sync(), or which criteria the kernel follows, but as a matter of fact a write happens every few seconds.

Looking at the code, it looks like it's impossible to instruct LMDB to use MAP_PRIVATE without modifying the code. But before exploring that solution, I'd like to be sure I understand the real behaviour of LMDB.

Doesn't MAP_PRIVATE imply that the map can't be written to disk?

Do I understand correctly, that if during the lifetime of my process the same key is assigned different values, with mdb_txn_commit() being called each time, the same addresses in the shared memory area will be changed several times (leading to unnecessary re-writes of the same area of the flash storage)? Or is LMDB only operating in "append" mode, so that it tries to avoid writing the same area twice?

I think no DB system can implement a commit with just one write.

Why not put your DB im a RAM disk and then rsync to flash when done?

Regards, Ulrich

Thanks in advance for any answer, Alberto

-- http://www.mardy.it - Geek in un lingua international