Date: Tue, 23 Mar 2010 10:27:25 -0400 From: John Baldwin <jhb@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> 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: <201003231027.25874.jhb@freebsd.org> In-Reply-To: <Pine.GSO.4.63.1003221942200.20197@muncher.cs.uoguelph.ca> References: <4BA3613F.4070606@comcast.net> <201003221339.37169.jhb@freebsd.org> <Pine.GSO.4.63.1003221942200.20197@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003231027.25874.jhb>