FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian KDE

 
 
LinkBack Thread Tools
 
Old 05-12-2010, 12:53 AM
Mike Kasick
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

Folks,

I've looked around the "KDE 4.4.3 in unstable" thread and elsewhere, and I
didn't see this specific issue come up, although I think it's generally
well known.

In any event, I upgraded my unstable machine today, which was a few weeks
behind, and it pulled in KDE 4.4.3. First thing I noticed was my home
directory was less 141 MB. Furthermore, if I create a new user account,
and do nothing but login and logout of a KDE desktop, the home directory
takes up 141 MB with no real data!

I'll be frank for a moment. Regardless of whatever technical issues have
arisen in recent history, it is _simply unacceptable_ that a system upgrade
should suddenly eat 141 of /home, especially without warning!. It is
similarly unacceptable that a new, empty user account also takes up this
much space. I know disk space is cheap and plentiful these days, and that
Google is willing to store 7453.767074 MB of my email, but certainly I must
not be alone in the belief that an empty user account taking up 141 MB of
disk space is absurd.

Alright, so here's the backstory:

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.

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. Thus burdening every KDE user, including brand
new user accounts, with akonadi/mysql/141 MB less disk space. I suppose
that's "fine" for anyone who might actually benefit from it--although I
consider it a blatant waste of disk space. But it's surprising at best,
and downright aggravating at worse, to those of us who are trying to avoid
this entire mess.

In any event, this problem can be avoided by simply running "kwriteconfig
--file kres-migratorrc --group Migration --key Enabled --type bool false"
[1] prior to upgrading to KDE 4.4, or prior to running "startkde" as a new
user account, although the latter results in the KDE 3 => 4 migration
dialog popping up.

There's a couple solutions to this problem.

- Long term: Don't use MySQL as the default Akonadi backend, which is
currently infeasible.

- Disable "kres-migrator". Or at least add a debconf option to
kdepim-runtime presenting the option of running kres-migrator by default
or disabling it.

- Add a warning dialog during kdepim-runtime upgrade stating that
kres-migrator will run by default and potentially consume a large amount
of per-user disk space, unless migration is manually disabled by the
above command.

- 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!

I suppose the last option is the best for going forward with KDE PIM 4.4 in
squeeze. Hopefully someone familiar with InnoDB tuning can comment on what
a reasonable transaction log size is for the expected, typical Akonai
transaction volume, and Debian can configure to use the minimum reasonable
value by default.

Apologies for my rant. I just can't comprehend how such disk usage is even
remotely acceptable for PIM usage patterns.

Thanks to anyone who addresses the issue, and to the KDE packagers for
their patience in dealing with user complaints. =)

[1] http://techbase.kde.org/Projects/PIM/Akonadi#How_do_I_disable_automatic_migration_from_ KDE.27s_traditional_framework.3F


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100512005320.GA16379@club.cc.cmu.edu">http://lists.debian.org/20100512005320.GA16379@club.cc.cmu.edu
 
Old 05-12-2010, 08:41 AM
Kevin Krammer
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

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
 
Old 05-12-2010, 08:48 AM
Richard Hartmann
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

On Wed, May 12, 2010 at 02:53, Mike Kasick <mkasick-dk@club.cc.cmu.edu> wrote:

> - Long term: Don't use MySQL as the default Akonadi backend, which is
> *currently infeasible.

It is my understanding that KDE 4.5 will let you choose different
backends.


> - Disable "kres-migrator". *Or at least add a debconf option to
> *kdepim-runtime presenting the option of running kres-migrator by default
> *or disabling it.

Did you do any research as to what the longer-term implications
of foregoing this might be? I am not saying there are any, I
honestly don't know.


> - Add a warning dialog during kdepim-runtime upgrade stating that
> *kres-migrator will run by default and potentially consume a large amount
> *of per-user disk space, unless migration is manually disabled by the
> *above command.

Personally, I would like to see such a warning, but I am not sure if
that is acceptable by Debian's standards. apt-listchanges exists for
a reason.


> - Reduce the default size of the InnoDB transaction logs in the Akonadi
> *per-user MySQL configuration.

Seems like the best bet to me. If need be, the file size could be adapted
automagically. But that functionality would be in 4.5 at the earliest unless
it's patched downstream.


> Apologies for my rant. *I just can't comprehend how such disk usage is even
> remotely acceptable for PIM usage patterns.

Having only two users per machine and a huge /home anyway, I did not
notice this, but I agree that this is an issue that should be addressed.

Also, what about /root?


Richard


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTim5DSUzpyUrf5PqgBiXmYCLX_f0Mw0_wfVYSgeg@mail .gmail.com">http://lists.debian.org/AANLkTim5DSUzpyUrf5PqgBiXmYCLX_f0Mw0_wfVYSgeg@mail .gmail.com
 
Old 05-12-2010, 02:51 PM
Alejandro Exojo
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

El Miércoles, 12 de Mayo de 2010, Mike Kasick escribió:
> Apologies for my rant. *I just can't comprehend how such disk usage is even
> remotely acceptable for PIM usage patterns.

Thanks a lot for doing this research. I've noticed that Akonadi takes a lot of
space in ~/.local and I was concerned, but I didn't know what was causing
this.

I think that disk usage is an issue in most software, not just KDE apps. For
example, look at ~/.thumbnails, and you will see that is probably filled with
many thumbnails of images that you deleted long ago or that you saw just
once. Same thing for apps that store some data about all files that you open,
without limit and without expiration.

--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005121651.24377.suy@badopi.org">http://lists.debian.org/201005121651.24377.suy@badopi.org
 
Old 05-12-2010, 03:09 PM
Christoph Burgmer
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

Am Mittwoch, 12. Mai 2010 schrieb Alejandro Exojo:
> I think that disk usage is an issue in most software, not just KDE apps.
> For example, look at ~/.thumbnails, and you will see that is probably
> filled with many thumbnails of images that you deleted long ago or that
> you saw just once. Same thing for apps that store some data about all
> files that you open, without limit and without expiration.

You can tell Gwenview to remove .thumbnails on exit.

-Christoph


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005121709.19874.christoph.burgmer@stud.uni-karlsruhe.de">http://lists.debian.org/201005121709.19874.christoph.burgmer@stud.uni-karlsruhe.de
 
Old 05-12-2010, 03:14 PM
Noah Meyerhans
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

On Wed, May 12, 2010 at 10:48:43AM +0200, Richard Hartmann wrote:
> > - Long term: Don't use MySQL as the default Akonadi backend, which is
> > *currently infeasible.
>
> It is my understanding that KDE 4.5 will let you choose different
> backends.

Recent threads on this list suggest that 4.5 will have a number of
improvements over 4.4. It's unfortunate that the release timings don't
line up well, because we're going to end up having to support 4.4 in
squeeze for a long time to come.

noah
 
Old 05-12-2010, 03:36 PM
Christoph Burgmer
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

Am Mittwoch, 12. Mai 2010 schrieb Noah Meyerhans:
> On Wed, May 12, 2010 at 10:48:43AM +0200, Richard Hartmann wrote:
> > > - Long term: Don't use MySQL as the default Akonadi backend, which is
> > > currently infeasible.
> >
> > It is my understanding that KDE 4.5 will let you choose different
> > backends.
>
> Recent threads on this list suggest that 4.5 will have a number of
> improvements over 4.4. It's unfortunate that the release timings don't
> line up well, because we're going to end up having to support 4.4 in
> squeeze for a long time to come.

4.4 was supposed to have major improvements over 4.3. 4.2 was supposed to fix
major issues of 4.1 and 4.0. Also called, I believe, the first "stable" version
of KDE 4.

I'd say none of the current versions can be called stable. Every new feature
seems to need at least two point versions to become stable. With currently
every new version having major new features I don't see a release coming soon
that could honestly be called stable.

4.5 will have similar improvements and new issues over 4.4 as that had over
4.3 as that had over 4.2 ...

Come to think of it, less expectations raised would've maybe led to less
disappointment.

-Christoph


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005121736.43081.christoph.burgmer@stud.uni-karlsruhe.de">http://lists.debian.org/201005121736.43081.christoph.burgmer@stud.uni-karlsruhe.de
 
Old 05-12-2010, 03:48 PM
"Boyd Stephen Smith Jr."
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

On Wednesday 12 May 2010 10:14:52 Noah Meyerhans wrote:
> On Wed, May 12, 2010 at 10:48:43AM +0200, Richard Hartmann wrote:
> > > - Long term: Don't use MySQL as the default Akonadi backend, which is
> > > currently infeasible.
> >
> > It is my understanding that KDE 4.5 will let you choose different
> > backends.
>
> Recent threads on this list suggest that 4.5 will have a number of
> improvements over 4.4. It's unfortunate that the release timings don't
> line up well, because we're going to end up having to support 4.4 in
> squeeze for a long time to come.

Options:
1. Conspire to keep the RC-bug count high enough on other packages for long
enough that KDE 4.5 gets into testing.
2. Convince upstream to to release KDE SC 4.4½.0 before the freeze, or roll
these new features into another KDE SC 4.4.x release before the freeze
3. Where possible, get the feature into Debian by working on the dependencies
outside of "KDE-proper".

I think I'm going to work on 3. Virtuoso, Akonadi, and Strigi (among others)
may be appropriate for a upgrade before either the freeze or the KDE SC 4.5.0
release. The KDE-integration parts might be missing, but as long as new
versions don't cripple KDE (AFAIK, their only "consumer" in Debian) new
upstream versions and bug fixes can be accepted until the freeze.

I'm against delaying a Debian freeze/release until after some particular
upstream release. If we routinely did that, whether for bug fixes or features
we'd never make a release. If it is an RC-bug, the fix can be backported.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 05-12-2010, 04:28 PM
Alejandro Exojo
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

El Miércoles, 12 de Mayo de 2010, Christoph Burgmer escribió:
> Am Mittwoch, 12. Mai 2010 schrieb Alejandro Exojo:
> > I think that disk usage is an issue in most software, not just KDE apps.
> > For example, look at ~/.thumbnails, and you will see that is probably
> > filled with many thumbnails of images that you deleted long ago or that
> > you saw just once. Same thing for apps that store some data about all
> > files that you open, without limit and without expiration.
>
> You can tell Gwenview to remove .thumbnails on exit.

The point of .thumbnails to be created, I thought it was to have the scaled
images already generated. If I did this, what's the point of having this
directory?

--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005121828.35294.suy@badopi.org">http://lists.debian.org/201005121828.35294.suy@badopi.org
 
Old 05-12-2010, 04:35 PM
Christoph Burgmer
 
Default KDE 4.4.3 upgrade eats 141 MB of /home

Am Mittwoch, 12. Mai 2010 schrieb Alejandro Exojo:
> El Miércoles, 12 de Mayo de 2010, Christoph Burgmer escribió:
> > Am Mittwoch, 12. Mai 2010 schrieb Alejandro Exojo:
> > > I think that disk usage is an issue in most software, not just KDE
> > > apps. For example, look at ~/.thumbnails, and you will see that is
> > > probably filled with many thumbnails of images that you deleted long
> > > ago or that you saw just once. Same thing for apps that store some
> > > data about all files that you open, without limit and without
> > > expiration.
> >
> > You can tell Gwenview to remove .thumbnails on exit.
>
> The point of .thumbnails to be created, I thought it was to have the scaled
> images already generated. If I did this, what's the point of having this
> directory?

You would at least have them available while using the current Gwenview
instance.

Not sure how Dolphin interacts with that.

-Christoph


--
To UNSUBSCRIBE, email to debian-kde-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005121835.54871.christoph.burgmer@stud.uni-karlsruhe.de">http://lists.debian.org/201005121835.54871.christoph.burgmer@stud.uni-karlsruhe.de
 

Thread Tools




All times are GMT. The time now is 02:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org