[kdepim-users] rant

[Martin Steigerwald]

Am Dienstag, 27. Januar 2015, 22:47:28 schrieb E. Hakan Duran:
> Hi all,

Hi Hakan,

> I guess I just wanted to rant a little bit about KDEPIM. I have been a
> loyal user of Kontact/Kmail/KDEPIM since 2003 or so. Back in the days
> of KDE 3, things would work flawlessly, then came KDE 4 and eventually
> the akonadi backbone for KDEPIM. I never gave up on the suite at its
> worst times mostly because of its flexibility for customization.
> Although I am ranting now, I don't see myself giving up on KDEPIM
> anytime soon. That being said, I am still disappointed with its current
> state. KDE 5 is around the corner now but I don't think KDEPIM 4.14.3
> is anywhere close to Kontact/Kmail 3.x.x when KDE 4 was about to be
> implemented. I just cleaned a *75 GB *
> ~/.local/share/akonadi/file_db_data folder, and decided to disable the
> offline mode for IMAP accounts, since those would start filling this
> folder again incredibly quickly. Disabling offline mode is not ideal
> either, since you need to wait a few or more seconds to be able to see
> the contents of an email. I also encountered a few problems over the
> course of the years, including corruption of the mysqllite database and
> having to recreate all my accounts from scratch, etc. There are a few
> more criticisms, but this should suffice for this email.

Wow, you hold a record. 75 GiB in ~/.local/share/akonadi/file_db_data – how 
large is your mail account? That is more than *ten* times larger than the 
maximum size I have seen on one of my systems. Are you sure it was 75 GiB?

And yeah, I think you found a real issue with the caching mechanism of 
Akonadi.

Have you checked how many files have been in there?

Also see:

[Akonadi] [Bug 338402] File system cache is inneficient : too many file per 
directory

Bug 332013 - NFS with NetApp FAS: please split payload files in file_db_data
into several directories to avoid reaching maxdirsize limit on Ontap / 
WAFL filesystem

Bug 341884 - dozens of duplicate mails in 
~/.local/share/akonadi/file_db_data

And please add your feedback to there, I suggest using 338402.

Please do it and point out in what way it causes an issue for you. So far, 
there is some idea that modern Linux filesystem cope with that amount of 
files in there, and well, they do, but I do think this amount of caching is 
excessive and way over the top. And your case of having 75 GiB in there, 
makes it abundantly clear.

One question regarding this, do you receive *very large* mails? In 
addition to the bug reports above, I think there may be another issue at 
play: If you receive very large mails with huge attachments and if Akonadi 
caches them, no wonder you get a large file_db_data. So I would really be 
interested in that. How many files did you have in there? Was it "just" a 
few very big files for very big mails, or was it hundreds of thousands (I 
am *not* kidding, maximum I saw here with a huge IMAP account is >850000 
files) of files?

As you cleaned the directory already, you cannot check how many duplicated 
mails you have in there, if you do have backup, please go check and also 
add it to the duplicate mail bug report about.

Also see my thread [Kde-pim] Akonadi(Next): Thoughts on caching on kde-pim 
mailing list.


And:

I tested a setting (SizeTreshold=32768) that seems to make Akonadi create 
*a lot* less files in there:

https://bugs.kde.org/show_bug.cgi?id=338402#c9

At the expense of a larger database.

I am only testing it since a few days, but so far it looks good.




Also, it seems that at least during some time after moving mails, Akonadi 
may *write* cache them into ~/.local/share/akonadi either in database (<4 
KiB with standars SizeTreshold setting) or as files (>4 KiB) and does not 
write the mail to its final location immediately, so if you are using local 
maildirs for storing mails either via POP3 or by moving mails from IMAP 
account to local maildir, then be cautious about cleaning file_db_data, as 
you may loose mails in that case. So better clean things with

akonadictl fsck

instead of manually removing files from there. You may add a higher 
SizeTreshold setting as well.

[kmail2] [Bug 338238] copied or moved mails are often not processed 
correctly (POP3)

[kmail2] [Bug 339181] moving mails from cached imap to local folder leaves 
mails without RID

> I used to love and admire Kontact/Kmail, now it is a love and hate
> relationship, just like a seasoned marriage. Unfortunately I lack the
> expertise to be able to contribute to the improvement of this now very
> complicated piece of software. I just hope something miraculous happens
> soon and the usability of KDEPIM improves significantly; both on a
> day-to-day basis and in the long term (see the rant above about
> significant accumulation of junk data in folders in time). As a
> consumer, I am yet to be convinced that the switch to akonadi backbone
> was a good decision.
> 
> I am sorry to take your time, and thanks to those who read up to this
> point.

I understand your mode.

I had my own share of issues with Akonadi.

Developers are aware of some of its shortcomings and there are plans for 
Akonadi Next which likely would do things quite a bit differently. It may 
even go without a RDMS like MySQL for caching, use mmap for efficient access 
and what not, there is a presentation about it, I think Aaron Seigo put it 
up in his blog.

There also have been database performance improvements with Akonadi git, 
also in 1.13 branch thats easily compilable.

However I agree to the principle of Akonadi in itself. Having the mail and 
PIM item handling separate from the mail program in a framework with some 
kind of database or caching is a very good idea in my oppinion.

Its just, that, IMHO, the implementation is lacking.

In addition to that, I think KDEPIM team needs more developers. It is just 
a few people working regularily on KMail, KDEPIM and Akonadi.

So it may take a while, and I think as to the current caching behaviour, 
please make your feedback heard in the bug report, best, based with some 
facts, so if you can check how many files you had in there from a backup, 
all the better.

I know it can be painful. I still think KMail is the best GUI based mail 
client I have ever seen. But issues with Akonadi make it difficult for me to 
enjoy it at times. And sometimes I want to throw it out of the window.

Thank you,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users