Date: Fri, 12 Sep 1997 19:19:31 -0600 From: "Mike Durian" <durian@plutotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: VFS/NFS client wedging problem Message-ID: <199709130119.TAA03040@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 13 Sep 1997 00:03:16 -0000."
next in thread | raw e-mail | index | archive | help
On Sat, 13 Sep 1997 00:03:16 -0000, Terry Lambert <tlambert@primenet.com> wrote: > >How do you serialize upcalls through the socket, such that you >don't have overlapped requests? Or do you have seperate request >contexts so that this doesn't cause problems? > >If you don't have seperate contexts, eventually you'll make a request >before the previous one completes. I serialize. I used to keep a list of N available sockets and use one socket per request, but since I handle commands atomically in the user process figured it was silly and dropped down to one socket. The user process is one big select loop, and doesn't call select again until it has completed all commands on the readable sockets (which is now just one socket). >The NFS export stuff is a bit problematic. I don't know what to >say about it, except that it should be in the common mount code >instead of being duplicated per FS. > >If you can give more architectural data about your FS, and you can >give the FS you used as a model of how a VFS should be written, I >might be able to give you more detailed help. > >This is probably something that should be taken off the general >-hackers list, and onto fs@freebsd.org It's really a mish-mash of other file systems. I grabbed some from cd9660 and msdosfs for NFS, socket stuff from portal and then nullfs and other miscfs filesystem for general stuff. I'll take all the detailed stuff off this list and move it to freebsd-fs. I didn't know the fs list existed. >That's not strange. It's a request context that's wedged. When a >request context would be slept, the nfsd on the server isn't slept, >the context is. The nfsd provides an execution context for a different >request context at that point. Try nfsstat instead, and/or iostat, >on the server. I didn't realize that. I did use nfsstat, but didn't know what to look for. The only thing that seemed interesting to me was the 190 server faults. But I didn't know if that was normal or not. >This proves to us that it isn't async requests over the wire that are >hosing you. That the server is an NFSv3 capable server argues that >the v2 protocol is implemented by a v3 engine, which would explain >the blockages. > >Have you tried bot TCP and UDP based mounts? Yes. UDP died locked up faster than TCP (though that is a subjective measurement, I didn't actually time things). TCP had the "server not responding"/"responding again" messages. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709130119.TAA03040>