From owner-freebsd-fs@FreeBSD.ORG Wed Jul 25 18:21:10 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FAEB16A418 for ; Wed, 25 Jul 2007 18:21:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from gigi.cs.uoguelph.ca (gigi.cs.uoguelph.ca [131.104.94.210]) by mx1.freebsd.org (Postfix) with ESMTP id C8FE713C474 for ; Wed, 25 Jul 2007 18:21:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by gigi.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l6PIL67f025911; Wed, 25 Jul 2007 14:21:06 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l6PIPYQ14848; Wed, 25 Jul 2007 14:25:34 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 25 Jul 2007 14:25:34 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: Jim Rees In-Reply-To: <20070725171214.GC25749@citi.umich.edu> Message-ID: References: <20070725171214.GC25749@citi.umich.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.210 Cc: freebsd-fs@freebsd.org Subject: Re: handling unresonsive NFS servers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 18:21:10 -0000 On Wed, 25 Jul 2007, Jim Rees wrote: > Afs has the same problem, and solves it by marking a server "down" when it > doesn't respond. The timeout is very long, like a minute or more. Normally > this would permanently hang the client, but once the server is marked down, > any subsequent operations fail immediately. The client checks periodically > to see if the server has come back up. Failing this way is better than > waiting forever, because waiting forever results in a reboot when the > machine's owner runs out of patience. Linux has something called a "lazy" umount, which I think is similar to the above, except that it is invoked by a sysadmin instead of a timeout (and doesn't come back, just umounts when the RPCs finally happen). I didn't see much use in it, but I can see that setting a mount point "not working for now" might be useful. > > And by all means, do fix umount -f. >