News for hackers. Stuff that matters.
Re:Lightning Memory-Mapped Database Manager (LMDB) 1.0 by tynorf on Thursday July 02, 2026 @08:01PM (#48768999)
IIRC: it is to leverage the OS page cache rather than having a separate buffer pool in user land. By default lmdb uses normal pwrite/fsync for the write path, but can optionally use a writable mapping and (presumably) msync.

However, some people think there are problems with this usage: (pdf warning) https://www.cidrdb.org/cidr2022/papers/p13-crotty.pdf

Re:Lightning Memory-Mapped Database Manager (LMDB) 1.0 by senderista on Saturday July 04, 2026 @03:40PM (#48788281)
How is pwrite/fsync any better than mmap/msync? Both go through the page cache and combine asynchronous writeback with forced flush. One theoretical advantage of pwrite might be that you can handle I/O errors, but I’d like to see a case where recovering from an I/O error makes sense (rather than just crashing the database, which SIGBUS would do anyway by default).
Re:Lightning Memory-Mapped Database Manager (LMDB) 1.0 by hyc_symas on Sunday July 05, 2026 @09:33AM (#48794217)
write/fsync can be faster in a large dataset because writes let the filesystem know an explicit list of dirty pages, so fsync only needs to deal with them.

mmap/msync gives no hints about which pages are dirty (unless the app tracks them itself and msyncs them individually, which would completely defeat any reduced syscall advantage of using a writable mmap in the first place) so the entire map must be scanned for dirty pages.

In practice, the expected performance advantages of using a writable mmap just aren't there, and coupled with the ease of silent corruption, it's best to never use that approach.