[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LMDB Crash-consistency
- To: OpenLDAP Technical <openldap-technical@OpenLDAP.org>
- Subject: LMDB Crash-consistency
- From: Howard Chu <hyc@symas.com>
- Date: Mon, 06 Oct 2014 19:38:43 +0100
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 SeaMonkey/2.27a1
Just an fyi... As you would know from reading the LMDB design papers
( http://symas.com/mdb/#pubs ) LMDB is crash-proof by design. A Symas client
already confirmed this in their own crash testing last year
https://symas.com/carrier-grade-stability-and-performance/ and it has again
been verified by a research group at the University of Wisconsin. Their
findings are being presented at the Usenix OSDI conference this week, and you
can read the paper here
https://www.usenix.org/conference/osdi14/technical-sessions/presentation/pillai
They report on a single "vulnerability" in LMDB, in which LMDB depends on the
atomicity of a single sector 106-byte write for its transaction commit
semantics. Their claim is that not all storage devices may guarantee the
atomicity of such a write. While I myself filed an ITS on this very topic a
year ago, http://www.openldap.org/its/index.cgi/Incoming?id=7668
the reality is that all storage devices made in the past 20+ years actually do
guarantee atomicity of single-sector writes. You would have to rewind back to
30 years at least, to find a HDD where this is not true.
The UWisc researchers' point is that we cannot say what behaviors will be
exported by up--and-coming nonvolatile RAM mechanisms (e.g. MRAM or PCRAM); if
they offer byte-addressability instead of sector-addressability then there's a
potential for these writes to become non-atomic in the future.
At any rate, this issue has zero relevance today, and we are monitoring all of
the upcoming NVRAM technologies closely for future developments.
The other takeaway from these reports is how critically unreliable many other
popular systems are. If you use any of the other projects that were included
in this research, you owe it to yourself to rethink that usage, or raise
discussions with their developers on how they plan to address their many
weaknesses.
As an interesting footnote, BerkeleyDB was included in the original testing,
and while it was in their preliminary results
http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf it is now
conspicuously absent from the final paper. Regardless, the OpenLDAP Project is
deprecating use of BerkeleyDB for multiple reasons. Again, if you're still
using BDB you need to take a moment to re-evaluate your project.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/