Red Hat Bugzilla – Bug 145401
slowdown when running programs from NFS mount
Last modified: 2015-01-04 17:15:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
Description of problem:
Running john the ripper from a NFS mounted directory will cause the system to become very sluggish. Copying the same program to a local disk and running from there, no slowdown.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install john the ripper on an NFS server and export this to a client
2. On the client, run: ./john -restore and observe sluggish system
3. cp -a run /tmp; cd /tmp/run; ./john -restore; and observe no slowdown
Expected Results: No system slowdown.
I don't know if this is the same problem, but on the kernel mailing list I spotted: http://lkml.org/lkml/2005/1/17/201
I have reproduced this on two kernels:
2.6.10-1.747_FC3smp on a Dell PE 2650
2.6.10-1.741_FC3smp on a Dell PE 6300/550
The problem does not exist on my dell D600 laptop: 2.6.10-1.741_FC3
Created attachment 109905 [details]
vmstat output running from NFS
This is output of vmstat during a slowdown. vmstat was started, then john was
started from an NFS mounted directory, run for a few seconds then killed.
system time looks interesting to me.
Created attachment 109906 [details]
vmstat output running from local disk
Same thing as previous except that this time we run from local disk. No
slowdown when we do this.
Created attachment 109907 [details]
strace out of slow john
strace of a running john on a slow system.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.