[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Akonadi mail caching (was: Re: Lost mail, etc.)



Hi Rainer.

Am Dienstag, 31. Januar 2017, 13:04:10 CET schrieb Rainer Dorsch:
> On Monday 30 January 2017 12:46:59 Martin Steigerwald wrote:
> > > I have a lot of data in
> > > 
> > > ~/.local/share/akonadi/file_db_data
> > > 
> > > If this directory is pretty much empty, then your mail is probably gone.
> > > If
> > > that directory is still huge, there seems to be some data left, not sure
> > > how you recover the content though (it seems to be one file per mail,
> > > you
> > > could open it with less or an other pager or editor).
> > 
> > Sorry, thats dangerous half-knowledge.
> > 
> > While it could be that something is in there, that Akonadi didn´t save
> > elsewhere (yet), Akonadi is still mostly a cache. The real mail data is
> > elsewhere.
[…]
> Is there a way to control the size of this cache?
> 
> Mine seems to be huge
> 
> rd@blackbox:~/.local/share/akonadi/file_db_data$ du -sh .
> 12G     .
> rd@blackbox:~/.local/share/akonadi/file_db_data$

Do you use Disconnected / Offline IMAP? I.e. let Akonadi cache copies of all 
mails locally. This is a checkbox in IMAP account settings somewhere named 
somewhat along the line "Download all mails" or so. I accidentally had this 
set on my company account and it generated a huge file_db_data as well as 
db_data, as it stores all mails below a certain size treshold (default 4 KiB) 
directly into the database and only uses file_db_data for mails larger than 
that.

Cause if that is set, Akonadi won´t expunge mails from its cache.

After I removed that setting (and after removing the database and letting it 
redo it, which means having to reconfigure all folder assignments, but as I use 
server side filtering this wasn´t much work to do)… I now got:

ms@merkaba:~/.local/share/akonadi> du -sch db_data file_db_data search_db ; find 
file_db_data -type f | wc -l
3,1G    db_data
1,1M    file_db_data
1,9G    search_db
5,0G    insgesamt
17

Which sounds reasonable for an account of about 15 GiB of mail. Currently 
there are only 17 files in file_db_data. This is only about last week I finally 
found that I had this setting active, so sizes, especially in file_db_data may 
go up a bit more.

Before db_data was almost as big as my whole account size as Akonadi cached 
*every* mail.

> and I would not mind reducing it to a lower single digit GB number.

I am not away of any other means to configure the cache size or cache duration. 
AFAIK there isn´t one.


Depending on the version of KDEPIM and Akonadi you started out with,

akonadictl fsck

may get rid of quite some of the files as there has been a file leakage bug 
(Akonadi forgetting about files in there). These are then in file_db-lost+found 
directory which you can safely remove afterwards.

And you can use

akonadictl vacuum

to compress database tables in db_data.

Make a backup first however.

All of this optimization steps have been topic on kdepim-users and I bet here 
as well. I really suggest subscribing to kdepim-users.

Also it would be helpful to document all these things in upstream wiki or 
Debian wiki. I think the generic stuff would be more suitable to go itno 
upstream wiki.

Thanks,
-- 
Martin


Reply to: