Comment 15 for bug 1322407

I made one more observation, and it is fully reproducible. Frankly, it would appear that the bug may not be as impactful as originally though (if this is a bug, to begin with). Here it is:

On one of the Linux clients, Windows runs in Virtualbox. The NFS share is mounted within the Linux host, and the mount point is available in the virtual environment as a vboxdrv shared folder. Within Windows, the user uses a translation automation tool called "Trados". If -- and only if -- this program is running, the apparent runaway kworker uses 100% CPU. When Trados is closed, the CPU core returns to idle within ~20 to 30 seconds.

This, finally, explains many observations I made before, which are mere coincidences. It also explains why a second NFS server that I brought online today does not exhibit the runaway behavior. Only the combination of all three: NFS, Virtualbox (Win 7 guest), and Trados, puts a heavy load on the rpc daemon. No other Windows program in the virtual box does that.

Why and how? I used tcpdump to see if anything insane is going on, but it is not -- neither on the client's physical eth0 interface nor on the virtual vboxnet0 interface. I did not find anything suspicious. Also, I cannot explain why the old 10.04 NFS server didn't show this behavior. NFSv3 perhaps? And why does it affect the rpc daemon?

In conclusion, I believe that I found the cause (albeit not the reason) for the runaway behavior. I also believe that the combination of software packages is very unusual, and this bug is not likely to affect many people. I propose to reduce the importance level of this bug to "low".

Latsly, it makes me shudder to think about what Trados might do to the hard disks of people who use it locally, with natively installed Windows.