https://bugs.kde.org/show_bug.cgi?id=336582
Bug ID: 336582 Summary: Sudden write interruption during akonadictl vacuum causes database corruption Classification: Unclassified Product: Akonadi Version: GIT (master) Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: critical Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de As Akonadi despite my changes to stop sorting of filenames in Maildir resources got slower and slower again, I thought I try akonadictl vacuum. I had a kernel compile running at that time and well… as it sometimes happens during heavy I/O BTRFS seemed to lock up. Thus I rebooted. On reboot the Akonadi database was corrupted. parttable.ibd and another file was zero byte long. Reproducible: Didn't try Steps to Reproduce: 1. Run akonadictl vacuum 2. Switch off the machine 3. Restart Actual Results: Database corrupted. Some files are zero byte. Expected Results: Database is intact. Why do I think this is a bug? Even with delayed allocation, if an application does proper renaming and fsync() the file is either renamed and written or not. I consider a cache for pim data important. And thus it has to use fsync(). This may well be something in MySQL at play here. Together with Bug 336581 New: accidental database loss causes Akonadi / KMail breaks correct folder assignments its even more important to never ever loose the database. Potential culprits in default mysql.conf for Akonadi: # Write out the log buffer to the log file at each commit (default:1) innodb_flush_log_at_trx_commit=2 And if default is 0: #sync_bin_log=0 Would be nice to have extra bugzilla entries for different DB backends. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs