More text.

diff --git a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
index 0184f287071b8ff98b3fe3efcb771ce0c6149175..6b297ac2741339b3c5263a9e01493bb19e14ab63 100644 (file)
--- a/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
+++ b/blog/data/2012-04-06-skolelinux-slowkdenfs.txt
@@ -1,14 +1,15 @@
 Title: Why the KDE menu is slow when /usr/ is NFS mounted - and how to fix it
 Tags: english, debian edu
 Title: Why the KDE menu is slow when /usr/ is NFS mounted - and how to fix it
 Tags: english, debian edu

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

 
 

-<p>Recently I have worked on speeding up a Skolelinux installation
-using LTSP diskless workstations, and in the process I discovered
-something very surprising.  The reason the KDE menu is responding slow
-when using it for the first time, is 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,
+<p>Recently I have worked on speeding up a
+<a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
+installation using LTSP diskless workstations, and in the process I
+discovered something very surprising.  The reason the KDE menu is
+responding slow when using it for the first time, is 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() system calls.  KDE
 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() system calls.  KDE


@@ -22,7 +23,7 @@ directories, and the list of possible directories is large.  In
 and .xpm.  The result is a very slow KDE menu when /usr/ is NFS
 mounted, as showing a single sub menu result in thousands of NFS
 requests.  I am not the first one to discover this.  I found a
 and .xpm.  The result is a very slow KDE menu when /usr/ is NFS
 mounted, as showing a single sub menu result in thousands of NFS
 requests.  I am not the first one to discover this.  I found a

-<ahref="https://bugs.kde.org/show_bug.cgi?id=211416">KDE bug report
+<a href="https://bugs.kde.org/show_bug.cgi?id=211416">KDE bug report

 from 2009</a> about this problem, and it is still unsolved.</p>
 
 <p>My solution to speed up the KDE menu was to create a package
 from 2009</a> about this problem, and it is still unsolved.</p>
 
 <p>My solution to speed up the KDE menu was to create a package


@@ -37,7 +38,8 @@ almost instantaneous.</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

-speed up that part.</p>
+speed up that part without replacing NFS with for example NBD, and
+that is not really an option at the moment.</p>

 
 

-<p>If you got feedback on this issue, please contact debian-edu (at)
-lists.debian.org.</p>
+<p>If you got feedback on this issue, please let us know on debian-edu
+(at) lists.debian.org.</p>