Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Mar 2010 19:53:23 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-fs@freebsd.org, Steve Polyack <korvus@comcast.net>, bseklecki@noc.cfi.pgh.pa.us, User Questions <freebsd-questions@freebsd.org>
Subject:   Re: FreeBSD NFS client goes into infinite retry loop
Message-ID:  <Pine.GSO.4.63.1003221942200.20197@muncher.cs.uoguelph.ca>
In-Reply-To: <201003221339.37169.jhb@freebsd.org>
References:  <4BA3613F.4070606@comcast.net> <201003221200.41607.jhb@freebsd.org> <4BA79E54.5030504@comcast.net> <201003221339.37169.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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:-)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.1003221942200.20197>