Messages in this thread | | | Subject | RE: [nfsv4] RE: Finding hardlinks | From | Trond Myklebust <> | Date | Wed, 03 Jan 2007 00:21:37 +0100 |
| |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |