Messages in this thread | | | Subject | Re: Can an NFS server legitimately duplicate directory entry cookies? | Date | Mon, 21 Sep 1998 21:33:45 -0300 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <98Sep21.194103edt.62314@pinkwind.utcs.toronto.edu>, Chris Siebenman n writes: +----- | It appears that a SGI NFS server (Irix 6.2) can sometimes return the | same directory cookie for two successive entries in the directory | (if I am tracing the code right, the cookie is stuffed in the dirent | structure's d_off member by the kernel's getdents(); otherwise, my test | program is printing something else). This appears to sometimes cause the | getdents() syscall to enter a state where it always returns the same entry. | | Is this legitimate behavior of the SGI NFS server implementation, and | thus a problem with the Linux NFS client nfs_readdir(), or is this an | SGI bug that I should club them about? +--->8
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/
| |