From owner-freebsd-fs@FreeBSD.ORG Mon Mar 22 23:40:27 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 24D751065672; Mon, 22 Mar 2010 23:40:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE0E8FC12; Mon, 22 Mar 2010 23:40:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK6cp0uDaFvK/2dsb2JhbACbKXO9G4R9BA X-IronPort-AV: E=Sophos;i="4.51,290,1267419600"; d="scan'208";a="69919885" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 22 Mar 2010 19:40:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id AB40E109C2EF; Mon, 22 Mar 2010 19:40:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8txDjRB+Ab4p; Mon, 22 Mar 2010 19:40:25 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 3C9CF109C2F4; Mon, 22 Mar 2010 19:40:25 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2MNrNa22445; Mon, 22 Mar 2010 19:53:23 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 22 Mar 2010 19:53:23 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <201003221339.37169.jhb@freebsd.org> Message-ID: References: <4BA3613F.4070606@comcast.net> <201003221200.41607.jhb@freebsd.org> <4BA79E54.5030504@comcast.net> <201003221339.37169.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Mon, 22 Mar 2010 23:40:27 -0000 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:-)