Bug 142462

Summary: kded prevents hard disk to sleep on laptop due to periodic fdatasync calls
Product: [Unmaintained] kdelibs Reporter: Casteyde.Christian <casteyde.christian>
Component: kdedAssignee: David Faure <faure>
Status: RESOLVED WORKSFORME    
Severity: normal CC: l.lunak, me, sami.liedes
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Casteyde.Christian 2007-03-03 16:06:48 UTC
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;
}
Comment 1 Luke 2007-08-28 03:52:50 UTC
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.
Comment 2 David Faure 2007-08-29 00:14:54 UTC
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.
Comment 3 Bram Schoenmakers 2007-12-09 23:50:18 UTC
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.
Comment 4 Casteyde.Christian 2007-12-10 19:12:25 UTC
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.
Comment 5 Sami Liedes 2008-04-19 03:04:25 UTC
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.
Comment 6 Casteyde.Christian 2008-04-19 08:59:59 UTC
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).
Comment 7 Lubos Lunak 2009-09-27 18:27:08 UTC
KDE4 does not use fsync/fdatasync unless $KDE_EXTRA_FSYNC is set, so this should not be a problem anymore.