Version: unspecified (using Devel) OS: Linux The proble is that the akonadi server with bundles mysql serve uses much and more disk space to make indexing of things regarded to mail. This is tollerable with a huge space leaved to the home directory. But in my situation I had "only" 2GB of disk free that akonadi occupied in a small amount of time. For my opinion there have to be a manner to remove akonadi services or to use a light version. As a side effect of the disk fullness I had to kill akonadi and mysql process, to clean the disk space. After That the migration from kde 4.4 had huge problems all related to the end of disk free space. Reproducible: Didn't try
I have this same issue. All my mail is stored on IMAP servers (I use dovecot on my local machine for local folders). KMail 1 used around 37M for everything (~/.kde/share/apps/kmail). Having created Akonadi resources for my IMAP connections, Akonadi has been steadily eating away at my disk space, until it ran out. `du -hs ~/.local/share/akonadi/db_data/akonadi/*` gives the following output: 12K collectionattributetable.frm 224K collectionattributetable.ibd 12K collectionmimetyperelation.frm 96K collectionmimetyperelation.ibd 12K collectionpimitemrelation.frm 96K collectionpimitemrelation.ibd 12K collectiontable.frm 144K collectiontable.ibd 4.0K db.opt 12K flagtable.frm 112K flagtable.ibd 12K mimetypetable.frm 112K mimetypetable.ibd 12K parttable.frm 1.5G parttable.ibd 12K pimitemflagrelation.frm 9.1M pimitemflagrelation.ibd 12K pimitemtable.frm 12M pimitemtable.ibd 12K resourcetable.frm 112K resourcetable.ibd 12K schemaversiontable.frm 96K schemaversiontable.ibd Even having deleted the resource that points at the localhost (where the bulk of my mail is - 1.2G on disk), and restarting the server, Akonadi still uses the same amount of disk space, and parttable seems to contain emails from the deleted resource.
Note: I haven't even attempted to access these emails, by using KMail or whatever. I ran the kmail migrator (which didn't manage to migrate all my accounts), but haven't accessed any akonadi email resources since.
I've run into the same problem (using 4.5.1 from the kde-unstable repo for Fedora) migrating a largish (just under ~115K messages total) IMAP config, after letting kmail-migrator run (which took quite a few hours). ~/.kde/share/apps/kmail was 215Mb ~/.local/share/akonadi is 3.6Gb (3.5Gb of that is parttable.ibd) The total server-side disk footprint of the two mailboxes (Dovecot maildirs) involved is ~2.7Gb, with around 250Mb of that being the dovecot indexes. In addition to that (or because of it?) some 4 hours after kmail migrator finished the machine is still nearly unusable - between mysqld, virtuoso-t, akonadi_nepomuk_email_feeder and akonadi_server the load has been sitting around 5 for the whole time.
I started using KMail again recently; this problem doesn't seem to appear any more. I've got pretty much exactly the same setup, but it's only using ~300Mb instead of nearly 2Gb (and 300Mb isn't unreasonable, given the number of emails that need to be indexed).
Yes, I confirm you that the issue seem to be addressed also for me: nepomuk-core-4.9.5-1.1.x86_64 ~> du -hs ~/.local/share/akonadi/db_data/akonadi/* 12K .local/share/akonadi/db_data/akonadi/collectionattributetable.frm 496K .local/share/akonadi/db_data/akonadi/collectionattributetable.ibd 12K .local/share/akonadi/db_data/akonadi/collectionmimetyperelation.frm 128K .local/share/akonadi/db_data/akonadi/collectionmimetyperelation.ibd 12K .local/share/akonadi/db_data/akonadi/collectionpimitemrelation.frm 96K .local/share/akonadi/db_data/akonadi/collectionpimitemrelation.ibd 44K .local/share/akonadi/db_data/akonadi/collectiontable.frm 176K .local/share/akonadi/db_data/akonadi/collectiontable.ibd 4,0K .local/share/akonadi/db_data/akonadi/db.opt 12K .local/share/akonadi/db_data/akonadi/flagtable.frm 112K .local/share/akonadi/db_data/akonadi/flagtable.ibd 12K .local/share/akonadi/db_data/akonadi/mimetypetable.frm 112K .local/share/akonadi/db_data/akonadi/mimetypetable.ibd 12K .local/share/akonadi/db_data/akonadi/parttable.frm 265M .local/share/akonadi/db_data/akonadi/parttable.ibd 12K .local/share/akonadi/db_data/akonadi/pimitemflagrelation.frm 16M .local/share/akonadi/db_data/akonadi/pimitemflagrelation.ibd 12K .local/share/akonadi/db_data/akonadi/pimitemtable.frm 37M .local/share/akonadi/db_data/akonadi/pimitemtable.ibd 12K .local/share/akonadi/db_data/akonadi/resourcetable.frm 112K .local/share/akonadi/db_data/akonadi/resourcetable.ibd 12K .local/share/akonadi/db_data/akonadi/schemaversiontable.frm 96K .local/share/akonadi/db_data/akonadi/schemaversiontable.ibd
Problem still exists here on KDE 4.13.0. ~/.local/share/akonadi$ du -csh * 4,0K akonadi_control.error 4,0K cur 1,8G db_data 4,0K db_misc 2,7G file_db_data 4,0K mysql.conf 4,0K new 0 socket-lapuntu 4,0K tmp 4,5G total Total size of all mailboxes is ~7GiB. Plus, baloo email cache (or whatever it is) eats up additional 2.5GiB.
Is there a fix for this? I ran into a similar issue. I'm connecting to a 30 GB IMAP mailbox. Until today, I used the option "download messages for offline use". I totally understand that Akonadi then uses the same amount of disk space as my mailbox is. However, now I unchecked the "download for offline use" option and restarted Akonadi. But I do not know how to tell Akonadi to free the disk space. $ du -h -d 0 ~/.local/share/akonadi/file_db_data 30G ~/.local/share/akonadi/file_db_data
I suspect this could be caused by bug 341884.
I just bumped into this bug on Mageia 5: Akonadi 1.13.0 Qt: 4.8.6 KMail: 4.14.5 My ~/.local/share/akonadi/file_db_data takes up around 86 GiB, which even though I have a 5 GiB IMAP inbox, is not *nearly* close to what it should be.
> My ~/.local/share/akonadi/file_db_data takes up around 86 GiB, which even > though I have a 5 GiB IMAP inbox, is not *nearly* close to what it should be. And sure enough, after cleaning it up with fdupes, the folder now takes only around 6 GiB of space.
Matija, thank you for your comment. Matija, did you read the previous comments and especially the hint to bug #341884? You are using an *ancient* version of KDEPIM and Akonadi that is not maintained anymore. Additionally the issue is likely already fixed. Please switch to at least KDEPIM/Akonadi 16.04 or 16.08, preferably 16.12. If you still have these issues with any of these versions, please open a new bug report. Closing as unmaintained. Thanks, Martin
(In reply to Martin Steigerwald from comment #11) > Matija, did you read the previous comments and especially the hint to bug > #341884? I did. That’s how I managed to work around it. > You are using an *ancient* version of KDEPIM and Akonadi that is not > maintained anymore. Additionally the issue is likely already fixed. Please > switch to at least KDEPIM/Akonadi 16.04 or 16.08, preferably 16.12. If you > still have these issues with any of these versions, please open a new bug > report. Mageia’s stable is still and carrying that version of KDE(PIM) and Akonadi. I’m anxiously waiting for Mageia 6 to finally come out in the next (hopefully) weeks – and with it the Plasma 5 (LTS)! I’m optimistic that I won’t stumble upon this bug again, but if I do, I’ll open a new bug, as instructed. Thanks :) > Closing as unmaintained. Thanks, Martin Sounds OK to me.