KDE4 on Debian Squeeze - permanent disk activity keeps drive from spindown
Well, the heading says it.
It looks like I am struck by this bug: https://bugs.kde.org/show_bug.cgi?id=198420 https://bugzilla.redhat.com/show_bug.cgi?id=488268 https://bugs.launchpad.net/ubuntu/+s...ce/+bug/546724 "plasma-desktop" is writing to some "icon_cache"-file every some seconds, so the hard disks never spin down. This is annoying, as it is a raid system, so more than one hard disk is affected. This even happens when the machine is completely idle, with display on standby. So there is no desktop activity at all. I couldn't find any traces of this for KDE on Squeeze so I supposed it not to be affected. Obviously I am wrong. Any solution is welcome, including an alternative to KDE. Basically I just need a desktop with a decent file manager like Konqueror and a terminal. A more comfortable solution would make me happier, of course. I am thinking about moving this icon_cache stuff to ramdisk, but it is quite large. Is there any way to simply disable the icon cache? Any further results about this on Squeeze? Am I the only one affected? |
You could install something like LXDE and then just run Konqueror and konsole within that desktop.
Can you change the icon cache file to read only for all users? Do you know what process has a hold of the icon cache file (maybe lsof could tell you)? |
Quote:
I suppose, when I run Konqueror on LXDE, I will loose KDE-IO-Slaves and probably more functionality. I checked some more Squeeze installations for this bug and it shows up everywhere. I can't fully believe it but it seems that KDE on Squeeze is broken for notebook/power saving use. Quote:
Actually, write access does not go to "kde-icon-cache", but to "kde-icon-cache.updated", "kde-icon-cache.lock" and "kde-icon-cache.index". Maybe it is sufficient to prevent KDE from creating these "updated" and "lock" files by making the directory "read-only". This shouldn't break anything as I suppose the lock files to serve getting exclusive access to the icon cache and if there is no lock file, there shouldn't be write tries. Is there any way to hook into screen saver activation/deactivation? If so, one could block the directory on activation and unblock it on deactivation. I've learned some more details about this icon cache thingy in the meantime. First, you can safely delete them ... they will be recreated. Second, they are not as big as they seem to be. They are spare files. So, ca. 150 MB of filesize go down to ca. 1 MB of actual hard disk use for freshly created icon caches. The icon cache consists of pixmap graphics. Icon templates are written in SVG for KDE4 and to speed up the display of the icons, precomputed pixmaps are stored in the icon cache. So far, I've relocated the whole directory to ramdisk via mount --bind. Any idea on how to relocate just the lock files? They change their name on each creation, so a softlink will not do the trick. Quote:
|
Well, to make a very long story appealingly short ...
It turned out that I still had "kpowersave" installed and running. It should have been removed during the upgrade from Lenny to Squeeze, but for some unknown reason, it didn't. After purging kpowersave, the write activity to the icon cache reduced dramatically. Besides that, locking the directory by changing its ownership to root, works quite well, so far. It resulted in some writes to .xession-errors (what was what pointed me to kpowersave). I'm still investigating on how to disable some unneeded stuff in KDE4, like desktop search and other sources of unwanted disk activity. I found useful hints on how to hook into screensaver activation here: http://www.linuxquestions.org/questi...nsaver-728498/ not sure, if I'll need to, though. This icon cache thing in KDE4 is annoying. Any window activation causes disk write access. But, for me, I consider this issue "solved", as the only thing I wanted was no disk access when the screensaver is running. Besides that, I found "suspend to ram" to work very well for me with Squeeze - the machines are back online and serving within 8 seconds, with an average power-usage of less than 5 watts when idle. So I am now investigating on how to adapt this feature to my needs. |
All times are GMT -5. The time now is 12:31 PM. |