From owner-freebsd-current Mon Jun 1 11:40:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01873 for freebsd-current-outgoing; Mon, 1 Jun 1998 11:40:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01867 for ; Mon, 1 Jun 1998 11:40:56 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id CAA10468; Tue, 2 Jun 1998 02:40:32 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806011840.CAA10468@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Kevin Day Cc: current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 11:55:45 EST." <199806011655.LAA13043@home.dragondata.com> Date: Tue, 02 Jun 1998 02:40:31 +0800 From: Peter Wemm 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. > 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. What age -current kernel sources are we talking about BTW? This kind of information is going to be pretty important from now on. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message