Francois Gnu writes: Yes, if the filesystem and operating system are so protected and you don't use mdb's dbnosync option. MDB needs no recovery. You may lose the last commit or two, but the database will be consistent if the filesystem is correct. However, note that your OS and harddisk may both be lying when they claim they've really written your data. MDB does not attempt to deal with data which got broken that way. Some databases do try. The OS part should be tunable with OS/filesystem parameters. Basically fsync() or fdatasync() need to actually write to disk. Harddisk writes get secured with builtin batteries to keep the disk going long enough to save the cache, RAID/SAN setups and I don't know what else. (I'm way out of date with this stuff.) Explanation: A database commit needs to be flushed to disk, and the data involved needs to be written in the right order (data before metadata). Which needs of physical seeks on the disk, and doing a lot of those can slow down not just the program doing it but the entire system - since other disk I/O may need to wait for these seeks too. To speed things up, normal file operations just write to caches in the OS and can return success before the cache has been written to disk. MDB calls fdatasync() to flush this to disk before returning success. But so do plenty of other programs, which can slow the system right back down. So to speed things up again, fdatasync() may ALSO be lying. And probably your harddisk too. It caches written data and returns success which actually just means "Got it, this'll get written". -- Hallvard

Thank you very much for these well detailed answers. Librement, ------ Francois Trachez (kiko) Team Fedora|Lyon (France) http://stg.fedoraproject.org/fr/ http://stg.fedoraproject.org/es/ 2012/8/24 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no&gt;:

Howard Chu writes: Oh duh, I forgot the sync filehandle. I thought dbnosync could cause database corruption: Data and metadata writes can get flushed out of order to the disk, leaving the meta page temporarily pointing at garbage - at which time an OS crash or hardware failure can make the inconsistency permanent. Frequent checkpoints merely reduce the chance such a crash has of catching the DB in an inconsistent state. (OTOH a mere slapd crash is no problem.) That's like if we compiled with -DMDB_DSYNC=0? -- Hallvard