Wrap up post.

diff --git a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
index b786bb7b0fcbf2433896e6f908629af9b334d45b..476de911834e9175c8675c9d2577d046bf3a8762 100644 (file)
--- a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
+++ b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
@@ -1,22 +1,25 @@
-Title: Why the KDE menu is slow when /usr/ is NFS mounted - and how to fix it
+Title: Why the KDE menu is slow when /usr/ is NFS mounted - and a workaround

 Tags: english, debian edu
 Tags: english, debian edu

-Date: 2012-04-06 22:20
+Date: 2012-04-06 22:40

 
 <p>Recently I have spent time with
 <a href="http://www.slxdrift.no/">Skolelinux Drift AS</a> on speeding
 up a <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
 Lenny installation using LTSP diskless workstations, and in the
 process I discovered something very surprising.  The reason the KDE
 
 <p>Recently I have spent time with
 <a href="http://www.slxdrift.no/">Skolelinux Drift AS</a> on speeding
 up a <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
 Lenny installation using LTSP diskless workstations, and in the
 process I discovered something very surprising.  The reason the KDE

-menu was responding slow when using it for the first time, was due to
-the way KDE find application icons.  I discovered that showing the
-Multimedia menu would cause more than 20 000 IP packages to be passed
-between the LTSP client and the NFS server.  Most of these were NFS
-LOOKUP calls, resulting in a NFS3ERR_NOENT response.  Looking at the
-strace of kicker in Lenny (or plasma-desktop i Squeeze - same problem
-there), I see that the source of these NFS calls are access(2) system
-calls for non-existing files.  KDE can do hundreds of access(2) calls
-to find one icon file.  In my example, just finding the mplayer icon
-required around 230 access(2) calls.</p>
+menu was responding slow when using it for the first time, was mostly
+due to the way KDE find application icons.  I discovered that showing
+the Multimedia menu would cause more than 20 000 IP packages to be
+passed between the LTSP client and the NFS server.  Most of these were
+
+NFS LOOKUP calls, resulting in a NFS3ERR_NOENT response.  Because the
+ping times between the client and the server were in the range 2-20
+ms, the menus would be very slow.  Looking at the strace of kicker in
+Lenny (or plasma-desktop i Squeeze - same problem there), I see that
+the source of these NFS calls are access(2) system calls for
+non-existing files.  KDE can do hundreds of access(2) calls to find
+one icon file.  In my example, just finding the mplayer icon required
+around 230 access(2) calls.</p>

 
 <p>The KDE code seem to search for icons using a list of icon
 directories, and the list of possible directories is large.  In
 
 <p>The KDE code seem to search for icons using a list of icon
 directories, and the list of possible directories is large.  In


@@ -35,7 +38,8 @@ icon file to /var/lib/kde-icon-cache/.  Finally, I add symlinks to
 these icon files in one of the first directories where KDE will look
 for them.  This cut down the number of file accesses required to find
 one icon from several hundred to less than 5, and make the KDE menu
 these icon files in one of the first directories where KDE will look
 for them.  This cut down the number of file accesses required to find
 one icon from several hundred to less than 5, and make the KDE menu

-almost instantaneous.</p>
+almost instantaneous.  I'm not quite sure where to make the package
+publicly available, so for now it is only available on request.</p>

 
 <p>The bug report mention that this do not only affect the KDE menu
 and icon handling, but also the login process.  Not quite sure how to
 
 <p>The bug report mention that this do not only affect the KDE menu
 and icon handling, but also the login process.  Not quite sure how to