https://bugs.kde.org/show_bug.cgi?id=356357
--- Comment #9 from k...@web.de --- (In reply to Riku Voipio from comment #8) > (In reply to kdeu from comment #7) > > Are there any experiences whith using LMDB and NOSYNC? > > Personally I've happily used that with patch attached since filing this bug > - except for a handful of upgrades when I forgot the patch, only to notice > that suddenly the disk light flashing means jittery UI again. I mean experiences with many users, and with crashes. If you don't test for crashes that's not a test for data corruption. You probably didn't crash your computer on purpose. > You are assuming that under current configuration LMDB can't get corrupted. > File systems are nasty and even with fdatasync there are caveats. That's not true. Without NOSYNC, LMDB is safe and does not get corrupted. See: http://openldap-devel.openldap.narkive.com/k1bbhN5H/lmdb-crash-consistency-again#post7 > All in all a bunch of bogus reporting; claiming that all DBs are broken when > in fact LMDB is perfectly correct > But for > most users, sudden crashes (especially in middle of transactions) is really > rare events. There are linux users who suffer from frequent power outages. > we used to get lots of bug reports which were because of corrupted databases > Recovering the DB is somewhat pointless - you can just > regenerate it from scratch, if under idle iopriority the indexing really has > no user impact. Yes you can regenerate from scratch, but how do you detect when to have to do that? This concern was already mentioned in comment #2: > I'm a little conflicted about this approach since when the index does get > corrupted, > it will be impossible for us to detect it. With our previous backend > (xapian), we > used to get lots of bug reports which were because of corrupted databases :( -- You are receiving this mail because: You are watching all bug changes.
