From kde-devel  Sat Apr 19 14:44:48 2008
From: Sami Liedes <sliedes () cc ! hut ! fi>
Date: Sat, 19 Apr 2008 14:44:48 +0000
To: kde-devel
Subject: fsync() madness
Message-Id: <20080419144448.GF6012 () nun4 ! kyla ! fi>
X-MARC-Message: https://marc.info/?l=kde-devel&m=120861637525158
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1157677156=="


--===============1157677156==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="B0nZA57HJSoPbsHY"
Content-Disposition: inline


--B0nZA57HJSoPbsHY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

I did some investigation with latencytop and noticed that a lot of KDE
applications fsync() continuously. Is there *any* good reason to do
so? As far as I understand, doing this just defeats the write back
cache, and if I wanted to do that, I'd mount my file systems noasync.

Normal applications should pretty much never fsync(). It's not a
matter of "this data is important", which seems to be the rationale
for KDE fsync()ing. I trust cp to copy my configuration files, and it
doesn't fsync(). The passwd command doesn't fsync() either, and if it
did, I'd file a bug against it. I measured latencies of >9 seconds on
a moderately disk-loaded system with loads of memory which would
handle this kind of load easily were it not for KDE unnecessarily
fsync()ing.

For example, take a look at K3TempFile. It says:

 * The K3TempFile class creates and opens a unique file for temporary use.
 *
 * This is especially useful if you need to create a file in a world
 * writable directory like /tmp without being vulnerable to so called
 * symlink attacks.

The class supports sync()ing. Can anyone invent a single reason why a
_temporary_ file should ever be fsync()ed? After all nobody depends on
it after a system crash, which is the only case where fsync() is
useful.

In K3TempFile, the sync() method both fflush()es and fsync()s, the
former of which makes sense, and the latter of which I think is just
braindead.

fsync() is explicitly allowed to be a null operation, so by definition
nothing should break if all the calls to fsync() are removed. I guess
I'm going to try to disable fsync() for KDE (3.5.9) since I trust my
kernel to write the stuff to disk eventually, it should break nothing
and help a lot, and since I haven't yet figured out any reason for a
single KDE application to fsync() (though some very isolated cases
might exist, e.g. postgresql and syslogd do fsync() for a good reason,
although for the latter it can still be disabled and usually is
disabled for non-critical log files).

Another code with I believe high impact that fsync()s with absolutely
no reason, and *by default*, is KConfig. I couldn't figure out with a
brief look if this is still the case in KDE 4, but at least in KDE
3.5.9 it does.

On Linux, I believe fsync() on NFS is a null op. On some other systems
it is not. This also makes some things unexpectedly slow on those
other systems, again for no good reason.

Makes me wonder if the people who wrote this code actually understood
the difference between fflush() and fsync().

Related bugs:

http://bugs.kde.org/show_bug.cgi?id=110318
http://bugs.kde.org/show_bug.cgi?id=142462
http://bugs.kde.org/show_bug.cgi?id=90042
http://bugs.kde.org/show_bug.cgi?id=146789

	Sami

--B0nZA57HJSoPbsHY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFICgVgyc0QC7DZBM8RAqw0AJsHQtnImZEkmVfJSIukBuka6MtDtACgrT4W
NnI/nWNkhZiBx+w0j4KOM7g=
=OO6p
-----END PGP SIGNATURE-----

--B0nZA57HJSoPbsHY--

--===============1157677156==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1157677156==--