Akonadi cache size 5 times too large with Kontact kolab_resource

Hello,

the size of the akonadi data in the user's home directory
is more than 5 times the size of the data.
After trying the documented ways to reduce it, 
I'm asking here about your advise. 

 * Should I file a problem report with bugs.kde.org?
   Or is there any other way I can help to improve 
   akonadi / Kontact? Maybe by offering some diagonistic info?

 * Is there something that I could / should try?

Otherwise I'll completely remove akonadi's data and config and
start with a fresh configuration.

Any hints are appreciated and thanks for being active for a Free Software
solution! :)

Best Regards,
Bernhard

== Symptoms
On the old Kontact Enterprise3.5 which uses a dimap cache, the data size is 
about 3 GByte. On the new Kontact the directory has over 17 GByte.
A part of this maybe the baloo index, but it still is way too much.

This new setup has been a configuration on OpenSUSE that has been migrated a 
couple of times. Probably going back to 13.2, then LEAP 42.1, 42.2, 42.3 and 
now LEAP 15.0.

With the last migration the kolab proxy resource was deleted, the IMAP 
resource deleted manually and the new kolab_proxy resource freshly added.

Tried
  akonadictl fsck
  akonadictl vacuum
and an initial full sync ran through, though sometimes there was a stop 
because space was lacking. There are servers on the folder that are not IMAP 
subscribed and also some folders were "locally" unsubscribed and vanished
from the folder list in Kontact Mail.
I've deleted the baloo cache once.

Expectation: The needed disk cache should be roughly the size of the combined 
emails, a maximum of factor 2 allowing for some uncleared data and a search 
index that probably is a little less than 100% of the data because not 
everything is high entropy full text.

== Hypothesis
Working hypothesis: there is unreferenced data still cached and not cleared 
somehow.

Rough idea:
It may have been gotten there when resources got migrated, deleted, others 
added or if folders were synced but later "unsubscribed" in some ways.

Speculating: it is an old setup with lot of data and kolab object use,
this maybe a difference to other setups. Many folks that are close to akonadi 
and Kontact development way probably re-setup more often.


== Details, References
This is Kontact and akonadi from release 17.12 
for official OpenSUSE LEAP 15.0, e.g for example

akonadi-server-17.12.3-lp150.1.2.x86_64.rpm
(There is a newer version in a different repo, but so far I'd expect it to not 
make a difference, do you?)

Ran searches on bugs.kde.org and the Akonadi wiki pages.
Found no IRC channel to reasonably ask. (#akonadi on freenode did not let me 
in without registration).

Tried to search kdepim-users, e.g. found and read
https://kde.markmail.org/message/r3qnxyolwfhuvdsm?q=list:kdepim-users+cleanup

The problem with some of the pages, internet search engine results and posts 
is, that is often is unclear how correct the information still is. Even with 
user and techbase. Still nothing really written about this ratio or larger 
unreferenced data remaining. 

The reset would be done like described here (in German)
https://wiki.ubuntuusers.de/Akonadi/


-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEELheSPXYdkVSywaF2PEP0yO/11CoFAlxQDgQACgkQPEP0yO/1
1Cq6VQf9EkBDofJAM990K2fjvN5cc2poACHLvJeJEj5a8RqB4ZFGH9MR9DTrC5Ji
nyawfeSz+kt9kKungON41NKCAhG5OgeAuF89Tb4AHd3AF2aZarmag8/qut/PWJIK
H2KV571ckw7xJSgLE8LokyUZZsIXMHyZFifDJdEXv1CMpNOBhwy9fmOQ4NWrtzLl
aWuETKKTPZX0+jJOWmIA6KXFmZ+U6ymZvPJaIRbfMR6xh54cJaZ6zhLHS3aO26lJ
NBxtb9meZXV8Q3DTXB6UjBIWgtdZm7dhG0tYgPCUXhoAc2Bwi6FagPpRZwUgthwG
GtajhsH1rynzgO3gTVg044rRsH6l3g==
=I0YP
-----END PGP SIGNATURE-----