From owner-freebsd-fs@FreeBSD.ORG Tue Mar 23 14:28:04 2010 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 2E3E0106566C; Tue, 23 Mar 2010 14:28:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F229F8FC0A; Tue, 23 Mar 2010 14:28:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A2D3B46B92; Tue, 23 Mar 2010 10:28:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id EEBEF8A026; Tue, 23 Mar 2010 10:28:02 -0400 (EDT) From: John Baldwin To: Rick Macklem Date: Tue, 23 Mar 2010 10:27:25 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BA3613F.4070606@comcast.net> <201003221339.37169.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003231027.25874.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 23 Mar 2010 10:28:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org, bseklecki@noc.cfi.pgh.pa.us, User Questions Subject: Re: FreeBSD NFS client goes into infinite retry loop 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: Tue, 23 Mar 2010 14:28:04 -0000 On Monday 22 March 2010 7:53:23 pm Rick Macklem wrote: > > That I have no idea on. Maybe Rick can chime in? I'm actually not sure why > > we would want to treat a FHTOVP failure as anything but an ESTALE error in the > > NFS server to be honest. > > > As far as I know, only if the underlying file system somehow has a > situation where the file handle can't be translated at that point in time, > but could be able to later. I have no idea if any file system is like that > and I don't such a file system would be an appropriate choice for an NFS > server, even if such a beast exists. (Even then, although FreeBSD's client > assumes EIO might recover on a retry, that isn't specified in any RFC, as > far as I know.) > > That's why I proposed a patch that simply translates all VFS_FHTOVP() > errors to ESTALE in the NFS server. (It seems simpler than chasing down > cases in all the underlying file systems?) Ah, I had read that patch as being a temporary testing hack. If you think that would be a good approach in general that would be ok with me. -- John Baldwin