Some of it them, possibly most of it us. I tend to see a lot of weirdness
with AFS (especially with getcwd()) because Linux assumes that a sort of
"provisional inode number" returned by AFS during getdents() is permanent,
whereas AFS will substitute the real "inode number" when it actually
accesses the object referenced by the entry. This presumably could happen
any time the filesystem object named by a directory entry can't be properly
tagged with a unique identifier until after it has been (equivalent of)
stat'ed by the network client, and for performance reasons the getdents()
operation in the client doesn't do this automatically.
Why it would happen with NFS is an interesting question --- presumably mount
points, since symlinks would be handled locally. (If the SGI NFS server
handles symlinks itself, any symlink to a directory could produce confusion,
as getdents() would return the symlink's (modified for NFS) inode number but
stat'ing the directory itself would return the inode number of the target.)
With AFS much the same is true, and sure enough the getcwd() weirdness
happens when we cross an AFS volume mount point and either the directory
containing the mount point or the root directory of the mounted volume isn't
in the cache.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/