Messages in this thread | | | Date | Thu, 28 May 1998 14:53:52 -0700 | From | (Pete Wyckoff) | Subject | Re: nfs v2.1.103 alpha staleness |
| |
I'm afraid the knfs won't work for me, but I'll give it some more work before completely giving up. Using a normal user-space rpc.nfsd is what gives rise to the errors below, but I suspect some client interaction due to the fact that "it works" under 2.0.30.
The root filesystem is mounted read-only, and no one is modifying the contents on the server. I played with a variety of attribute caching parameters and found that the first error message occurs <acregmin> seconds after boot. So I crank up all of ac{reg,dir}{min,max} to 5 minutes or so, let the system quiesce until then, then try running, say, uname:
su2cn3$ uname -a nfs_revalidate_inode: lib/ld-2.0.5.so getattr failed, ino=151011339, error=-70 NFS: bad fh 0900400b48470b04000000dc0000000000000000000000000000000000000000 0900400b48470b04000000dc0000000000000000000000000000000000000000 bash: /bin/uname: Stale NFS file handle su2cn3$ uname -a nfs_revalidate_inode: lib/libc-2.0.5.so getattr failed, ino=151011343, error=-70 NFS: bad fh 0900400f48470b04000000dc0000000000000000000000000000000000000000 0900400f48470b04000000dc0000000000000000000000000000000000000000 uname: error in loading shared libraries libc.so.6.1: cannot map file data: Stale NFS file handle su2cn3$ uname -a Linux su2cn3 2.1.103 #5 Tue May 26 11:29:04 PDT 1998 alpha unknown
Then things work fine for another 5 minutes.
I'll go see if I can port linux-nfs-0.4.21 to glibc2.0 and alpha before complaining too much more about unfsd. Right now the compile of the kernel part of knfs goes fine, and it will register itself with the portmapper on 2049 from a nfsservctl() syscall, but not respond to any requsets. The mountd still does the right thing.
-- Pete
Bill Hawes wrote: > Pete Wyckoff wrote: > > > > I repeatedly see console messages of the form: > > > > nfs_revalidate_inode: lib/ld-2.0.5.so getattr failed, ino=151011339, error=-70 > > NFS: bad fh 0900400b48470b04000000dc0000000000000000000000000000000000000000 > > 0900400b48470b04000000dc0000000000000000000000000000000000000000 > > > > on an NFS client which mounts its / filesystem. Both server and client are > > linux-alpha v2.1.103. When the server is v2.0.30, same problem. When the > > client is v2.0.30, no such problems. 70 is ESTALE on the alpha. > > Hi Pete, > > The stale filehandle message was added to try to track down the cause of > these sporadic failures. The first line shows the filehandle the client > is currently using, and the second line shows the result of a new lookup > -- i.e., what the server thinks the fh _should_ be. What's really > puzzling is that in your case the two are identical, making it appear > that the failure is spurious. > > I would have expected the two fh values to differ in some way, or for a > lookup error to occur when trying to get the current fh (e.g. if someone > else deleted the file on the server.) > > Are you using the knfs server or the unfsd? Any pattern to the messages? ----------------------------------------------------- Pete Wyckoff | wyckoff@ca.sandia.gov Sandia National Laboratories | 925 294 3503 (voice) MS 9011, P.O. Box 969 | 925 294 1225 (fax) Livermore, CA 94551 |
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |