From owner-freebsd-questions@FreeBSD.ORG Tue Mar 23 13:37:59 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A841065675 for ; Tue, 23 Mar 2010 13:37:59 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id DF00F8FC28 for ; Tue, 23 Mar 2010 13:37:58 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Tue, 23 Mar 2010 09:52:46 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::1526 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-questions@freebsd.org X-SMFBL: ZnJlZWJzZC1xdWVzdGlvbnNAZnJlZWJzZC5vcmc= Message-ID: <4BA8C434.30805@comcast.net> Date: Tue, 23 Mar 2010 09:37:56 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100311 Thunderbird/3.0.1 MIME-Version: 1.0 To: Rick Macklem , John Baldwin , freebsd-fs@freebsd.org References: <4BA8B2CB.1090905@comcast.net> In-Reply-To: <4BA8B2CB.1090905@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: User Questions , bseklecki@noc.cfi.pgh.pa.us Subject: Re: Fwd: Re: FreeBSD NFS client goes into infinite retry loop X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 13:37:59 -0000 On 03/22/10 19:53, Rick Macklem wrote: > > On Mon, 22 Mar 2010, John Baldwin wrote: > > >> It looks like it also returns ESTALE when the inode is invalid (< > >> ROOTINO ||> max inodes?) - would an unlinked file in FFS referenced at > >> a later time report an invalid inode? > >> > > I'm no ufs guy, but the only way I can think of is if the file system > on the server was newfs'd with fewer i-nodes? (Unlikely, but...) > (Basically, it is safe to return ESTALE for anything that is not > a transient failure that could recover on a retry.) > > >> But back to your point, zfs_zget() seems to be failing and returning the > >> EINVAL before zfs_fhtovp() even has a chance to set and check zp_gen. > >> I'm trying to get some more details through the use of gratuitous > >> dprintf()'s, but they don't seem to be making it to any logs or the > >> console even with vfs.zfs.debug=1 set. Any pointers on how to get these > >> dprintf() calls working? > > I know diddly (as in absolutely nothing about zfs). > > > > 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?) > > rick, chiming in:-) > > > Makes sense to me. I'll continue to bang on NFS with your initial patch in my lab for a while. Should I open a PR for further discussion / resolution of the issue in -CURRENT / STABLE? Thanks, Steve Polyack