From: Uresh Vahalia (vahalia@emc.com)
Date: 05/14/99-10:56:53 PM Z
Message-ID: <373CF084.61D17A03@emc.com> Date: Fri, 14 May 1999 23:56:53 -0400 From: Uresh Vahalia <vahalia@emc.com> Subject: Re: New file handle section > On Fri May 14 05:58:12 1999, Spencer Shepler wrote: > > > > 3.2.1. General Properties of a File Handle > > > > In the case that two different path names when traversed at the > > server terminate at the same file system object, the server must > > return the same file handle for each path. This can occur if a > > hard > > link is used to create two file names which refer to the same > > underlying file object and associated data. For example, if paths > > /a/b/c and /a/d/c refer to the same file, the server will return > > the > > same file handle for both path names traversals. > > > Many current NFS implementations encode a mount point handle as part of the file handle. Hence if a client has mounted server:/a on /mnt and server:/a/b on /mnt/foo, then the file handles for /mnt/b/x and /mnt/foo/x will be different, although they both refer to the same file. 3.2.1 is a major departure from v2 and v3 requirements, without much reason to justify it. If it is considered necessary, can we at least restrict it to within the same client mount point? This would protect the clients from the cache consistency issues Peter mentions, while allowing servers to encode mount point or connection information in the file handle. By the way, regarding the cache consistency issues, when a client receives an NFS handle, does it usually compare it with all the other handles to make sure there is no other file with an identical handle? Uresh
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:02 AM Z CST