From owner-freebsd-hackers Sat Mar 27 16:54:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0414214D07 for ; Sat, 27 Mar 1999 16:54:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA20231; Sat, 27 Mar 1999 16:53:57 -0800 (PST) (envelope-from dillon) Date: Sat, 27 Mar 1999 16:53:57 -0800 (PST) From: Matthew Dillon Message-Id: <199903280053.QAA20231@apollo.backplane.com> To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu Subject: Re: More death to nfsiod References: <199903271737.MAA25896@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I recently performed the upgrade to the machine that we were having NFS :toubles with. It is not -STABLE as of yesterday. We are still experiencing :weird NFS problems on it, and killing nfsiod still resolves most of them. :At the end of this email is a script(1) session deomonstrating some of the :problems. : :I looked at nfsiod, and I have no idea how it works, or even why it is needed. :It apparently only consists of a single system call that never returns, :nfssvc(NFS_BIOD, NULL); (or similiar). Normally when a process issues a write() op over NFS, it must be issued synchronously from the process's context even if the kernel issues the write asynchronously internally. nfsiod processes allow the kernel to pass of these synchronous requests to a free nfsiod process so it doesn't stall the process trying to write(). This is also true ( I believe ) of read-ahead requests. The nfsiod processes just stick around in supervisor mode and pickup async NFS requests that the kernel passes onto them. :This bug was tickeled by performig the folowing tasks on the NFS mounted :directory (NFSv2/UDP from a server of the eaxact same build). :First I did a "mkisofs112 -J -o netscape.iso .netscape" .netscape contains about 70M of data, 12209 files, and 38 directories. I tickeled the bug before by :using mkisofs112 to create an iso image of ie5.0 (arround 60M, 50 files, no directoreis). None of the mkisofs's have ever finished while nfsiod is running. That caused the symptoms, but resolved after a short time. then I issued a :... :inc: [install-mh aborted] :sh-2.02$ pwd :/amd/stagger/home1/a/crossd :sh-2.02$ ls -la /amd/stagger/home1/a/crossd :ls: /amd/stagger/home1/a/crossd: Not a directory If any of your NFS mounts are running over AMD, please try running mkisofs using direct NFS mounts ( non-amd ) and see if that fixes your problem. I've so far been able to run mkisofs over NFS V3 mounts without any trouble, but I'll run my test script overnight and also try it with NFS V2 mounts. It would be helpful if you d escribed what the bug was... all I know is that the mkisofs's don't finish. Ok... is the rest of the system still operable? Does it lock up? Crash? What does 'ps axl' say? etc. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message