On Wednesday, 2010-05-12, Mike Kasick wrote: > KDE 4 uses Akonadi as its PIM storage backend. Akonadi, at least in > unstable, only supports MySQL (and PostgreSQL) as backends. And the > default configuration of Akonadi is to run a per-user instance of MySQL > with InnoDB tables with two 64 MB transaction logs. Apparently such has > been the case for a while, and anyone who has been using KDE PIM > applications has probably noticed such. > > But I _don't_ use KDE PIM! I don't even have kdepim installed. Since you are writing a bit down that you think it is caused by kres-migrator, where did you get it from (here it seems to be part of the kdepim-runtime package). > The only reason why I even have akonadi-server and mysql-server-core > installed is because kde-minimal ultimately depends on them, and I'd rather > not micromanage my KDE packages. > > In any event, Akonadi is a known problem, and many folks are unhappy about > kdepim 4.4's inclusion in squeeze, etc. It's not worth going into that > here. > > Point is, up until now, folks who didn't use KDE PIM applications never had > to worry about akonadi/mysql/141 MB. But apparently in KDE 4.4, > kres-migrator automatically migrates the old KResource mechanism to an > Akonadi-backed data store. kres-migrator is called when an application accesses the KResource framework, e.g. some app accessing the old addressbook API. Not using KDEPIM apps does not necessarily mean non of your other applications access PIM data. > Thus burdening every KDE user, including brand > new user accounts, with akonadi/mysql/141 MB less disk space. I guess one possible improvement would be to have /etc/skel include a kres- migratorrc with migration being disabled. > There's a couple solutions to this problem. > > - Long term: Don't use MySQL as the default Akonadi backend, which is > currently infeasible. Actually it is currently only one of two feasable solutions. The other one being Postgres. Virtuoso's SQL interface is not up to the task yet and SQLite. while most working already, has still some problems (last I heard about it). > - Reduce the default size of the InnoDB transaction logs in the Akonadi > per-user MySQL configuration. I'm not familiar enough with InnoDB tuning > to offer an appropriate value, but I would suggest 4 MB to be the upper > limit of a reasonable per-user log size, it terms of what I'm comfortable > spending towards unproductive disk usage. Presumably if 64 MB is the > default, it's intended for databases with somewhat significant > transaction volumes. I expect that in average usage, Akonadi sees very, > very few transactions relatively speaking. If one can get away with a 1 > MB transaction log or less, even better! Anyone know what kind of data is stored in these logs? Does the necessary size depend on the number of accesses, number of operations per transaction or amount of data in transactions? Cheers, Kevin
Attachment:
signature.asc
Description: This is a digitally signed message part.