On Tue, 2010-04-20 at 17:22 +1000, Neil Brown wrote: > Hi Trond et al, > > It has come to my attention that NFS directories don't behave consistently > in terms of cache consistency. > > If, on the client, you have a loop like: > > while true; do sleep 1; ls -l $dirname ; done > > and then on the server you make changes to the named directory, there are > some cases where you will see changes promptly and some where you wont. > > In particular, if $dirname is '.' or the name of an NFS mountpoint, then > changes can be delayed by up to acdirmax. If it is any other path, i.e. with > a non-trivial path component that is in the NFS filesystem, then changes > are seen promptly. > > This seems to me to relate to "close to open" consistency. Of course with > directories the 'close' side isn't relevant, but I still think it should be > that when you open a directory it validates the 'change' attribute on that > directory over the wire. > > However the Linux VFS never tells NFS when a directory is opened. The > current correct behaviour for most directories is achieved through > d_revalidate == nfs_lookup_revalidate. > > For '.' and mountpoints we need a different approach. Possibly the VFS could > be changed to tell the filesystem when such a directory is opened. However I > don't feel up to that at the moment. I agree that mountpoints are problematic in this case, however why isn't '.' working correctly? Is the FS_REVAL_DOT mechanism broken? The other thing is that we should definitely expect the VFS to call nfs_opendir() once it has opened the file. > An alternative is to do a revalidation in nfs_readdir as below. i.e. when > readdir see f_pos == 0, it requests a revalidation of the page cache. > This has two problems: > 1/ a seek before the first read would cause the revalidation to be skipped. > This can be fixed by putting a similar test in nfs_llseek_dir, or maybe > triggering off 'dir_cookie == NULL' rather than 'f_pos == 0'. > 2/ A normal open/readdir sequence will validate a directory twice, once in the > lookup and once in the readdir. This is probably undesirable, but it is > not clear to me how to fix it. > > > So: is it reasonable to view the current behaviour as 'wrong'? > any suggestions on how to craft a less problematic fix? nfs_opendir() should fix case 1/, but still has the issue with case 2/. How about just having it force a revalidation if we see that this is a mountpoint? Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
