Howard Chu wrote:
Hallvard Breien Furuseth wrote:
On 15/11/14 02:57, Howard Chu wrote:
Ah good point. If you check out their slides, #103 of 106 asks the question; the only failure they found in LMDB occurred on ext3 (and not on XFS) so we may just chalk this up to a flaw in ext3 instead.
Given that ext3 has already been superseded by ext4, this result of theirs may not be all that useful in the real world. We already have disrecommended ext3 for performance reasons, perhaps we should just note this and move on.
No, ext4 breaks too. Their paper's page 459, 5.1.2 LightningDB:
The fact that the journal commit block (op#402) is flushed with the next pwrite64 in the same thread means fdatasync on ext3 does not wait for the comple- tion of journaling (similar behavior has been observed on ext4).I guess O_DSYNC and fdatasync() should not be the lmdb defaults yet, at least not on Linux:-(
We need a bug report to Linux or to the distro they were using, noting that the power faults are simulated. And is this O_DSYNC, fdatasync or both? The problem might be with only one of them. I'm not reading the paper in detail yet.
This appears to be quite old news.
https://lkml.org/lkml/2012/9/3/83
It has references going back to at least 2008.
The LKML thread indicates that this bug was already fixed. The zheng mai paper says they used RHEL6, which shipped with kernel 2.6.32 so it apparently was too old to have the fix.
All in all a bunch of bogus reporting; claiming that all DBs are broken when in fact LMDB is perfectly correct.