Date: Mon, 8 Aug 2005 16:10:06 GMT From: "Thom O'Connor" <thom@communigate.com> To: freebsd-gnats-submit@FreeBSD.org Subject: i386/84673: NFS client problem "Stale NFS file handle" Message-ID: <200508081610.j78GA6vo072309@www.freebsd.org> Resent-Message-ID: <200508081620.j78GKDun052603@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 84673 >Category: i386 >Synopsis: NFS client problem "Stale NFS file handle" >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Aug 08 16:20:13 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Thom O'Connor >Release: 5.4-STABLE >Organization: CommuniGate Systems >Environment: FreeBSD sys8.cluster 5.4-STABLE FreeBSD 5.4-STABLE #0: Wed Aug 3 21:13:51 PDT 2005 root@sys8.test:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD sys7.cluster 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: Using FreeBSD as an NFS client and testing it against various NFS servers, it appears that FreeBSD is incorrectly handling file caching data to lead to situations where the error message "Stale NFS file handle" (errno.h error 70). I've been able to repeat the problem using any of these operating systems: FreeBSD 5.4-STABLE FreeBSD 5.4-RELEASE FreeBSD 4.6-RELEASE I've tested against three different NFS servers, and the problem remained with each: RAIDZONE NFS array (linux 2.2 kernel) Linux 2.6 NFS server (SuSE 9.3) FreeBSD 5.4 NFS server (5.4-RELEASE) I've also tested on other operating systems, and none of these experienced this problem: Solaris 8 SPARC Linux 2.6 kernel (SuSE 9.3) Linux 2.6 kernel (SuSE 9.1) This seems to indicate the problem is with the FreeBSD NFS client code. Various NFS client mount options were tested, including tcp and mntudp, as well as setting nfs_access_cache="0" in /etc/rc.conf. None of these options affected the below behaviour. Any time the underlying file (and inode, I suppose) is renamed, the "Stale NFS file handle" error will occur. I am not an NFS expert by any means, but our product uses files on an NFS filesystem in this manner, and we've never seen this problem on any other OS (CommuniGate Pro is available on 37 platforms today). The NFS client should not be caching file handle data referenced by a unique identifier other than the filename itself, from what I know. Please contact me if you have any questions. Thank you. Sincerely, Thom O'Connor thom@communigate.com thom@interludium.com >How-To-Repeat: The problem is quite easy to replicate. Create an NFS server share, and mount that export on at least two systems, where at least one of the systems is a FreeBSD system. In the following example, both sys7 is FreeBSD 5.4-RELEASE and sys8 is FreeBSD 5.4-STABLE: Using /etc/fstab settings something like these (but varied for different tests): raidzone.cluster:/home/data /data nfs rw,nfsv3,-r32768,-w32768,intr 0 0 And then mounting that filesystem on both sys7 and sys8: sys7# mount /data sys8# mount /data Then perform these steps: sys8# cd /data sys8# touch testfile sys8# cat testfile sys7# cd /data sys7# touch testfile2 sys7# mv testfile2 testfile sys8# cat testfile cat: testfile: Stale NFS file handle >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508081610.j78GA6vo072309>