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.
It's odd that the file handle was just fine, so I'm suspecting data type size
discrepencies somewhere. Indeed, in fs/nfsd/nfsfh.c, line 895, there is:
struct inode *dir = ...
struct knfs_fh *fh = ...
if (dir->i_ino == fh->fh_dirino && dir->i_dev == fh->fh_dev) {
In struct inode (include/linux/fs.h),
unsigned long i_ino;
kdev_t i_dev; /* unsigned short in include/linux/kdev_t.h */
while fh->fh_dirino isa ino_t, which resolves via include/linux/types.h
to a __kernel_ino_t, which is (include/asm-alpha/posix_types.h):
typedef unsigned int __kernel_ino_t;
Similarly dev_t becomes an unsigned int by the same pathway.
So both these comparisons involve different types. Could this be the source
of the annoying staleness? I fear the patch may involve changing fundamental
sizes of things, and may break more than it fixes.
-- Pete
-----------------------------------------------------
Pete Wyckoff | wyckoff@ca.sandia.gov
Sandia National Laboratories | 510 294 3503 (voice)
MS 9011, P.O. Box 969 | 510 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