Date: Sun, 21 Mar 1999 19:41:01 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: freebsd-hackers@freebsd.org Cc: schimken@cs.rpi.edu Subject: Death to nfsiod Message-ID: <199903220041.TAA23505@cs.rpi.edu>
next in thread | raw e-mail | index | archive | help
Recently we have been having the problem of disk wait processes on our FreeBSD client machines (served from our FreeBSD servers of the same release, 3.1-STABLE). On the advice of Mike Smith I killed the NFS server processes on the FS, and then restarted them, this fixed the problem. We then recompiled all of our server machines with "maxusers 64" since that had been an apparent problem on another [remote access] server. However, this did not fix the disk wait processes or some other wierdness. As a bit of a torture test I used mkisofs to burn a Joliet IE5 cd iamge. I tried this test >10 times and every time *failed*. The failure would either be a disk-wait process or a wierd error with the output file (the 2 errors with the output file were both demonstrated with "ls *.iso", error 1 was : ie5.iso: protocol error. error 2 (this was much more common): ie5.iso: not a directory), after a couple of seconds the error would go away. Getting to the subject of the message, it has been observed that once a single process goes into this disk-wait state it becomes much more likely for additional processes to get there. While running the mkisofs one time I noticed that at the same time it went into disk wait a nfsiod went into (and remained) in disk wait. As a test I killed and restarted the NFSDs on the server (that woke both the nfsiod and the mkisofs), and then killed all nfsiods on the NFS client. The result is that I have again run mkisofs 10 times, now without a single failure or weird behaviour. -- David "The one long paragraph" Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903220041.TAA23505>