Version: inconnu (using KDE 3.5.4, compiled sources) Compiler: gcc version 3.4.6 OS: Linux (x86_64) release 2.6.20 It seems that one daemon (do not know which one) calls periodically fdatasync on a file, which causes caches to be flushed and force a write on the hard disk. While this is not important on desktop systems and when the computer is used, it is indeed annoying when either: a. the computer is a laptop with laptop mode enabled; b. the computer is idle and the user expects it to be silent. It may also tire the hard disk after a long time, because it forces the system to bypass its caches and does indeed a write every 3-4 seconds. My filesystems are already mounted with noatime, and I'm sure it's a call to fdatasync from kded, because I preloaded a nofsync.so library in start_kde which logs the called functions (sync, fdatasync and fsync) and the calling process pid, and it is clearly kded that does that. However, this behaviour is **not** systematic, sometimes kded keeps quiet. I could give file information if necessary because it is passed as an argument, but I didn't looked at it for now. Please ask me if you want. I post the nofsync.c file used to diagnose this problem. #include <stdio.h> //#define DEBUG_FSYNC #ifdef DEBUG_FSYNC extern int getpid(); extern int getppid(); #endif int sync() { #ifdef DEBUG_FSYNC static int i=0; FILE *f = fopen("/tmp/fsync.log", "a+t"); fprintf(f, "%d sync from pid %d (ppid %d)\n", ++i, getpid(), getppid()); fclose(f); #endif return 0; } int fsync (int __fd) { #ifdef DEBUG_FSYNC static int i=0; FILE *f = fopen("/tmp/fsync.log", "a+t"); fprintf(f, "%d fsync from pid %d (ppid %d)\n", ++i, getpid(), getppid()); fclose(f); #endif return 0; } int fdatasync (int __fd) { #ifdef DEBUG_FSYNC static int i=0; FILE *f = fopen("/tmp/fsync.log", "a+t"); fprintf(f, "%d fdatasync from pid %d (ppid %d)\n", ++i, getpid(), getppid()); fclose(f); #endif return 0; }
I can confirm similar trouble--kded wakes up my disk every 20-100 seconds when in laptop mode. Example output from lm-profiler: Accesses at 323/600 in run: [ 4279.996000] kded Accesses at 346/600 in run: [ 4304.004000] kded Accesses at 446/600 in run: [ 4410.996000] kded I'd be happy to do a little more testing to find out what is actually being written. I believe this takes about 30 minutes off of my battery life.
You need to find out which kded module does this. `dcop kded kded loadedModules` will show you the currently loaded modules. Now try to unload them one by one like this: dcop kded kded unloadModule kmilod until you find which one is responsible for this behavior.
Casteyde, Luke: do you have an idea which module causes this? Please follow the steps described by David Faure, otherwise I'm afraid we should close this bug due to insufficient information. It would be finding for a (possibly non-existing) needle in a haystack.
No, I didn't have any occasion to do these tests. The last time I got some hard drive spin up problem was with kget, but this was not kded.
I seem to have KDE 3.5.9 kded fsync()ing a lot too. I happen to be running multiple instances of kget with fast network connection at the moment too. According to latencytop, this occasionally blocks kded occasionally for as many as 3 to 8(!) seconds during heavy disk activity. This is not a laptop, but I believe things would be a lot faster if programs didn't do unnecessary fsync()s. Actually now that I take a good look, I get fsync() with 6+ seconds of latency in a konqueror process too.
The fsync problem is going to be pervasive. Indeed, with the gap between HDD latencies and other components nowadays, fsync seems to be the **real** big problem for both latency and power saving: it'll have to be adressed. For information (and other reasons), I've filled this kernel bug, since ext3 fsync implementation is also stupid: http://bugzilla.kernel.org/show_bug.cgi?id=9546 Basically, it states that both kmail and firefox 3 won't run on linux in the near term, which seems to me critical (but I consider all OS have the same problem). I consider fsync as a denial of service now. Software that uses fsync should really look for another way to ensure data is consistent, trusting the journaling filesystems. fsync should never have existed except for softwares such as databases and user space filesystems. By the way, I did a small .so that implements fsync, sync and fdatasync as nothing and I preloaded it: the problems vanished. See in the comments on kernel bugzilla for source (quite trivial).
KDE4 does not use fsync/fdatasync unless $KDE_EXTRA_FSYNC is set, so this should not be a problem anymore.