[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#364119: Discussion on KDE lists about f(data)sync()


I too noticed this as a truly major performance issue on my desktop
and can see how this is a problem on a laptop so I took the issue to
the kde-devel mailing list.

Unfortunately it seems that some KDE developers think fsync()ing data
to disk every now and then

1. is not a major performance issue, and
2. is actually good practice.

(I haven't given up hope yet they can be persuaded this is Wrong.)

Basically, nearly all fsync()s KDE does can be disabled by replacing
"result = FDATASYNC(mFd)" in kdelibs-3.5.9/kdecore/ktempfile.cpp by
"result = 0". This is a hack, but the only piece in KDE I have figured
out so far actually should need fsync() for anything is KShred (trying
to securely wipe files). As the fsync() system call is explicitly
allowed to be a nop (and is so for NFS on Linux I think, on some BSDs
it's not), this should not break anything unless your system crashes
or you lose power suddenly. Even then it's a risk pretty much every
software takes, and I think KDE shouldn't force synchronous file
access down my throat.

Anyway, I did the change I mentioned above, and the difference in
speed is truly amazing. KDE starts in a few tenths of a second,
Konqueror no longer makes me wait for seconds with medium disk loads,

According to one bug report and followup discussion, KMail even goes
as far as to issue sync() system calls to sync _all dirty kernel
buffers_, no matter whose, to disk[1], which is evil and broken
behavior enough to make me want to rm the kmail binary :). It should
be obvious this totally ruins the performance for any multiuser setup.

Here's the most recent thread I initiated:


and here are some older threads/mails discussing the issue:


Some KDE bugs related to the issue:



[1] http://bugs.kde.org/show_bug.cgi?id=90042

Attachment: signature.asc
Description: Digital signature

Reply to: