From owner-freebsd-hackers  Fri Sep 12 18:21:05 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA23772
          for hackers-outgoing; Fri, 12 Sep 1997 18:21:05 -0700 (PDT)
Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23749;
          Fri, 12 Sep 1997 18:20:58 -0700 (PDT)
Received: from shane.plutotech.com (shane.plutotech.com [206.168.67.149])
	by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id TAA03040;
	Fri, 12 Sep 1997 19:19:31 -0600 (MDT)
Message-Id: <199709130119.TAA03040@pluto.plutotech.com>
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 
In-reply-to: Your message of "Sat, 13 Sep 1997 00:03:16 -0000."
Date: Fri, 12 Sep 1997 19:19:31 -0600
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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