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