On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote: > Trond Myklebust wrote: > > > > On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote: > > > Mikulas Patocka wrote: > > > > > >BTW. how does (or how should?) NFS client deal with cache coherency if > > > >filehandles for the same file differ? > > > > > > > > > > Trond can probably answer this better than me... > > > As I read it, currently the nfs client matches both the fileid and the > > > filehandle (in nfs_find_actor). This means that different filehandles > > > for the same file would result in different inodes :(. > > > Strictly following the nfs protocol, comparing only the fileid should > > > be enough IF fileids are indeed unique within the filesystem. > > > Comparing the filehandle works as a workaround when the exported filesystem > > > (or the nfs server) violates that. From a user stand point I think that > > > this should be configurable, probably per mount point. > > > > Matching files by fileid instead of filehandle is a lot more trouble > > since fileids may be reused after a file has been deleted. Every time > > you look up a file, and get a new filehandle for the same fileid, you > > would at the very least have to do another GETATTR using one of the > > 'old' filehandles in order to ensure that the file is the same object as > > the one you have cached. Then there is the issue of what to do when you > > open(), read() or write() to the file: which filehandle do you use, are > > the access permissions the same for all filehandles, ... > > > > All in all, much pain for little or no gain. > > See my answer to your previous reply. It seems like the current > implementation is in violation of the nfs protocol and the extra pain > is required. ...and we should care because...? Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
