https://bugs.kde.org/show_bug.cgi?id=341192
--- Comment #6 from Martin Steigerwald <[email protected]> --- Rigo, yes, it doesn´t help to avoid the caching. And if you prefer the file based caching, then reduce the SizeThreshold again, yet for recoverability I think there isn´t that much of a difference as file_db_date directory has all files in one directory and with different names. Sure, you can use grep more easy to dig out the files, so by all means, if you don´t trust the database, reduce the SizeThreshold again. I think what you ask here for, and Rigo, I fully agree, is: A lower timeout for the write caching. As I wrote already: Have Akonadi write files to their final location more quickly. Not only on moving messages, but generally. The write caching should act like a filesystem journal: Try to write to the final location soon. Sure filesystems with a bigger journal work faster too, yet as you see it here, it takes ages for the files to appear in the final location. Hey, I can check it here as I moved some mails today. - kernel-ml-2015-1 according to KMail has 47834 unread mails. - kernel-ml-2014-1 according to KMail has only 27783 unread mails. - I moved about 30000 mails from the first to the second folder earlier today (see bug #345085 and bug #345084 for details on what I did and what issues I experienced with it) So lets check the filesystem: martin@merkaba:~/.local/share/local-mail/.Lichtvoll.directory/.Linux.directory> find kernel-ml-2014-1 | wc -l 28627 martin@merkaba:~/.local/share/local-mail/.Lichtvoll.directory/.Linux.directory> find kernel-ml-2015-1 | wc -l 49097 Okay, here it meanwhile moved the mails. Still I have no idea about on when Akonadi will be doing this and how long it will write cache under what circumstances. Additionally: I still don´t get why they have to go through file_db_data or the database at all. The most efficient implementation I see is this: Store the mails from the IMAP resource directly in the maildir in your case. And move the mails from source to destination database in my case, yet I also saw *huge* write activity to the MySQL database. Why cache? And why cache to this amount? Well, if the IMAP server can deliver the mails faster than the maildir resource could accept them, but then, Akonadi can still download the mails as fast as the maildir resource could accept them, downloading them faster will not give any benefit as the maildir resource couldn´t store them that fast, and I highly doubt that storing them in file_db_data or MySQL database would be any faster anyway. I sure hope that Akonadi Next will use a different approach if it leaves proof of concept state. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
