Bug 90042 - Should be able to disable incessant sync()ing
Summary: Should be able to disable incessant sync()ing
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: 1.7
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-22 19:41 UTC by Tom
Modified: 2012-08-19 00:48 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom 2004-09-22 19:41:54 UTC
Version:           1.7 (using KDE 3.3.0, Gentoo)
Compiler:          gcc version 3.4.1 20040803 (Gentoo Linux 3.4.1-r2, ssp-3.4-2, pie-8.7.6.5)
OS:                Linux (x86_64) release 2.6.8.1-ck5-kraxel

It seems that most actions like moving or deleting messages results in a disk sync.  I can see the advantage, but it makes tasks such as deleting spam and applying filters to a folder incredibly slow, even on a very fast computer.  I don't mind if there's a scary dialog telling me what a bad idea this is, but there ought to be a way to disable this.
Comment 1 Matt Douhan 2005-05-28 16:59:15 UTC
We do not think a config option like this is either 

1, Safe for the majority of the usres

2, Makes any sense KMail is a mail client not a config centre for the OS disk handling.

3, It is debatable if this is even possible on all platforms
Comment 2 Tom 2005-05-30 12:54:28 UTC
I don't think I specified the problem clearly.  It's not that the OS is scheduling disk syncs, there's no problem with that, because the OS does this asynchronously.  The problem, as indicated by strace, is that kmail is repeatedly issuing sync(2) system calls.  This tells the kernel to write out every dirty page to disk (even those unrelated to kmail's open files, at least kmail should use fsync instead of sync), hangs the kmail GUI until this operation is complete, and causes the system to become very slow.  If the user wants every dirty page to be written to disk immediately, he should set the sync flag in his /etc/fstab.  Individual applications should not take it upon themselves to call sync(2), especially not as unnecessairily often as kmail does.  You can have my write-caching when you pry it from my cold, dead hands :-)
Comment 3 Don Sanders 2005-06-09 09:52:37 UTC
I guess I don't object to the report being closed, but I would like to 
point out that the original reporter does have a valid point though. 
syncing is really slow.

The problem is there's a tradeoff between performance and losing data 
in the event of a hard crash. I decided to err on the side of safety 
but this has serious performance consequences.
Comment 4 Sami Liedes 2008-04-19 03:12:54 UTC
Hmm. I agree needless fsync()s are bad. Or does this cause some kind of breakage on nfs or something other weird stuff? Write caching is there for a reason, and it's plain stupid for normal applications to defeat it "just because".

I just used latencytop to measure fsync() times of >9 seconds on a heavily loaded machine with loads of memory for disk buffers, and that's exactly why I use write cache.
Comment 5 Myriam Schweingruber 2012-08-18 08:10:10 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 6 Luigi Toscano 2012-08-19 00:48:46 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.