From: Uresh Vahalia (vahalia@emc.com)
Date: 05/17/99-10:01:37 AM Z
Message-ID: <37402F51.44DBEDBC@emc.com> Date: Mon, 17 May 1999 16:01:37 +0100 From: Uresh Vahalia <vahalia@emc.com> Subject: Re: New file handle section (hard links) Peter Staubach wrote: > > > > > > > > This isn't an efficiency issue, unless the client can determine whether > > > or not it is safe to cache a particular file. If the client can determine > > > that it is not safe, then yes, disabling caching will solve the problem. > > > However, I don't believe that many people who actually have to use the > > > system are going to be too happy with this approach. If we can imagine > > > > What problem do you envision? Did you ever encounter it with V2 or V3, > > and what was your solution? > > > > Are you refering to the problem with performance or a problem with > cache consistency? > > > > it, it will happen. > > > > given the scenario Uresh explained, where /a/b/c is a hard link of > > /a/d/e, and /a/b and /a/d are each exported, this scenario exists > > today with V3 and V2. I've never seen a bug report from a customer. > > > > I don't know that I have seen a bug report, but I do know that I have > encountered the issue at Connectathon several times. The resolution > has always been the same -- Make the file handles the same. > > > The V3 specification from RFC1813 states: > > > > "If two file handles from the same > > server are equal, they must refer to the same file, but if they > > are not equal, no conclusions can be drawn. Servers should try > > to maintain a one-to-one correspondence between file handles and > > files, but this is not required. Clients should use file handle > > comparisons only to improve performance, not for correct > > behavior." > > > > And Despite Dave Noveck's recommendations to map two fh's with the > > same fsid, and file id to the same file, our client never has, and > > probably never will. Again, no ill effects noted. > > > > All NFS clients that I have ever worked on mapped the same file handle > to the same file on the file system. To the client, a unique file is > identified by the file handle. Different file handles mean different > files. What are you refering to? This uniqueness can only be within a particular mounted directory. How can a client expect two different servers, for instance, to coordinate and ensure no conflicts of file handles? Even if a server returns the same handle for the file when accessed through different mountpoints, it seems unlikely that any client is going to compare a handle to those on another mountpoint. Can any client developer shed some light on this? > > > ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:03 AM Z CST