From owner-freebsd-current  Mon Jun  1 12:45:11 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA14277
          for freebsd-current-outgoing; Mon, 1 Jun 1998 12:45:11 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14269
          for <current@FreeBSD.ORG>; Mon, 1 Jun 1998 12:45:06 -0700 (PDT)
          (envelope-from toasty@home.dragondata.com)
Received: (from toasty@localhost)
	by home.dragondata.com (8.8.8/8.8.5) id OAA21139;
	Mon, 1 Jun 1998 14:44:50 -0500 (CDT)
From: Kevin Day <toasty@home.dragondata.com>
Message-Id: <199806011944.OAA21139@home.dragondata.com>
Subject: Re: NFS discovery
In-Reply-To: <199806011840.CAA10468@spinner.netplex.com.au> from Peter Wemm at "Jun 2, 98 02:40:31 am"
To: peter@netplex.com.au (Peter Wemm)
Date: Mon, 1 Jun 1998 14:44:50 -0500 (CDT)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Kevin Day wrote:
> > 
> > Here's my setup:
> > 
> > 
> > 2.2.6 NFS server with /home exported
> > -current NFS client mounting server:/home under /home
> > 
> > If the server gets rebooted or their link is temporarily severed, the client
> > never recovers. Any attempt to read anything from /home causes the process
> > to get wedged pretty nicely. (even kill -9 won't kill it)
> 
> What's the wait channel that the client processes hang in BTW?  'ps 
> -axlww' and look for the hung process.

Next time it happens, I'll look.

However, I'm doubly out of luck as my nfs server os also my NIS server. ps
usually fails because it can't look up a user name... I'll see if it works.
:)

> 
> > However entering this on the client machine
> > 
> > mount -u -o async /home
> > 
> > *while* the client's nfs is hosed will make it recover within 5 seconds. It
> > even appears that all the writes that were queued are executed, and no data
> > is lost.
> > 
> > Is there any way of making whatever it was that did this happen
> > automatically every once in a while? :)
> > 
> > Does specificing async on an nfs mount even do anything?
> 
> It only specifies the commit level of writes.  An async nfs mount will 
> tell the server not to bother to sync write data to disk before returning 
> the rpc call.

Ok. I doubt actually setting it to async is doing it, rather just updating
it is fixing the problem. (doing mount -u -o async /home *again* will fix it
again and again. I'm wondering if just mount -u /home will do it or not.)

> 
> What age -current kernel sources are we talking about BTW?  This kind of
> information is going to be pretty important from now on.
> 

The client is from mar 25th. I can update if needed.

Kevin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message