[Akonadi] [Bug 341192] Moving messages does not synchronize to disk

[Martin Steigerwald]

https://bugs.kde.org/show_bug.cgi?id=341192

--- Comment #6 from Martin Steigerwald <Martin at Lichtvoll.de> ---
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 at merkaba:~/.local/share/local-mail/.Lichtvoll.directory/.Linux.directory>
find kernel-ml-2014-1 | wc -l
28627
martin at 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.