[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Akonadi] [Bug 341192] Moving messages does not synchronize to disk
From:       Martin Steigerwald <Martin () Lichtvoll ! de>
Date:       2015-03-12 18:12:31
Message-ID: bug-341192-17878-IqbRKg1Wrh () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #6 from Martin Steigerwald <Martin@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@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 watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]