Hi!

Using KDE 4.14 on arch (fully upgraded) and I set up an external mysql database for akonadi.
I am using this setup for two reasons:

- there is a mysql database running on my system anyway, so I prefer it to having too many instances of sqlite filebases running (seems like every second program now runs it's own sqllite...)

- my /home directory resides on a spinning HDD formated with btrfs, so to avoid too much disk activity due to CopyOnWrite, I try to keep VM-Images and big database files that are constantly changing of this disk...

Now for my question:
I turned on "external database" for akonadi and it seems to run fine. but still in "/.local/share/akonadi/" I have the folder "file_db_data" with 11210 elements inside. Those are not old files - the date stamp shows files have been recently changing every minute or so...

What's wrong here?

Akonadi does not store anything > 4Kb in the database, because it's inefficient: OTOH, each type of resource (IMAP, local folders) can implement its own storage (e.g. vcard for contacts). If you're using offline IMAP, file_db_data holds the message bodies of the mail you downloaded.

How or when do I use offline Imap?

I do not see any configuration for that.

The folder "~/.local/shar/akonadi/file_db_data holds 2.5 GB of data.
This is very surprising to me, because I use an external mysql database.
So there shouldn't be any data here, right?

thx, piedro

If you have "keep messages offline" (newer PIM version) or "enable disconnected mode" (older) for IMAP, message bodies are saved there, in file_db_data.

Ok, is there any way to read or import these message in the unlikely event something goes wrong with kmail?
(some way like in thunderbird - I could just reimport the dimap folder with the stored mail)

thx, p.

You can export data with the PIM settings exporter (under "Tools" in KMail).

Now this seems handy - I will test it right away....
I haven't even known this tool is there.

thx, p.

Be sure to have the latest version of KDE PIM, as this feature is still well-hidden and had a few bugs fixed only recently.

within the akonadi folder there is the folder "file_lost+found" containing 8,8 GB of data ...

Can it safely be removed, whats its purpose and if it is a kind of trashbin how to use it to restore files?

thx, p.

I'm not sure. I've never seen that on my system, to be honest. I'll ask around.

After I deleted the akondi folder and waited to rebuild it I get the following errors in akonadi:

DATABASE ERROR:
Error code: 1452
DB error: "Cannot add or update a child row: a foreign key constraint fails

...about 10000 instances...

also a lot of imap email bodies are now missing though I checked to keep offline copies and also tried to not keep offline copies...

What to do?

p.

Just to clear a few things: ~/.local/share/akonadi/file_db_data stores content of any data larger than 4 KB (be it email headers, email bodies, a contact, calendar event, etc.). The reason is to avoid having large tables in the database - there are some performance sideffects to storing large chunks of binary data in databases. It is possible to configure the treshold and force Akonadi to store even larger data than 4 KB directly into the database, but it will affect the performance in negative way unless you have lots of RAM and hand-craft your my.cnf.

lost+found can be deleted, it contains files from file_db_data that somehow became unreferenced - i.e. there is no record in database about them, but for some reason they were not removed from file_db_data when the record was removed from the database.

Deleting the entire ~/.local/share/akonadi is not enough. You also need to delete ~/.config/akonadi and ~/.kde/share/config/akonadi*. You also must wipe the database completely. And of course you must do it all while Akonadi is not running. Please note that wiping Akonadi is *not* a recommended solution to any problems.

Finally, if you are using Akonadi 1.13 or newer, you don't need to care about CoW on Btrfs, as Akonadi will disable CoW on ~/.local/share/akonadi folder and all its subfolders, if it detects Btrfs. This however only happens when the folder is first created, cannot be applied on existing folders/files.

Thx for that information!

For your information on the mssing content:
Most of the mails with missing bodies have been bigger than 4kb, I guess, because most of them have been html or multipart messages... but now even the single mail files in the "local folder" location hold no bodies of the affected mails.
They seem to have been stripped of their content somehow while the header is still there...

As you implied I'd rather not wipe akonadi completely cause this would mean to set up all mail accounts and transports again as all contact sources and so forth.... or am I mistaken here?

Where can I find any solution on how to go further? Most of the suggestions on this issue seem to be very much outdated, - I am a bit lost here.

Is there any "clean way" to recreate the database without reconstructing the whole akonadi setup?

Any help is very much appreciated,
thx for your efforts,
piedro

p.s.: the BTRFS change is great news!

You could try our fsck: first restart Akonadi from konsole:

Code: Select all

akonadictl restart

Once Akonadi is running again, open a new tab in konsole, and run

Code: Select all

akonadictl fsck

The command will return immediatelly, but the process will take long time on the Akonadi server (lets say 15 minutes), so be patient . You should see lots of output in the first tab, and in the end it usually prints something like "fsck done". If you don't see anything, just wait until Akonadi server stops using CPU and IO Also make sure you turn off KMail and all other apps that use Akonadi before you start.

After that opening every email (local or remote) will cause Akonadi to download the missing content from storage (maildir, IMAP server, ...), so if you use offline IMAP, it will be rather slow as no content will be available locally and each email will have to be downloaded once you open it (but only the first time, then it will be cached again).

If you just wipe everything, the initial fetch will get all content and you will be happy again

Next time: *don't* wipe your Akonadi