Date: Tue, 02 Jun 1998 02:40:31 +0800 From: Peter Wemm <peter@netplex.com.au> To: Kevin Day <toasty@home.dragondata.com> Cc: current@FreeBSD.ORG Subject: Re: NFS discovery Message-ID: <199806011840.CAA10468@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 01 Jun 1998 11:55:45 EST." <199806011655.LAA13043@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806011840.CAA10468>