From: Noveck, Dave (dave.noveck@netapp.com)
Date: 05/18/99-11:44:26 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA033035C8@TAHOE.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: New file handle section Date: Tue, 18 May 1999 09:44:26 -0700 Anybody tempted to flush this message should know this is *not* another rehashing of the semantics of SHOULD. > > Uresh wrote: > > 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. > > and later: > > This still does not handle the issue of encoding export or client > > mount-point information in the handle. Is this just an > omission, or do you > > specifically want servers to drop this component from their handles? > > I wanted to clarify that most NFS servers I know of generate > filehandles > based on the server export point, not the client mount point; > your example > would normally be confined to situations where the server > exported several > pieces of the same local filesystem. > > However, some our work on filesets has found it useful to > return filehandles > which also encode the client mount point. The intended use is to lock > /export/home/thurlow while it is turned into a fileset > without perturbing > other /export/home/* directories, but it could also lead to > more consistency > problems of the type we've been discussing. I think the > tradeoff makes sense > in this case, and am glad we're back to a SHOULD in the spec language. The thing I'm wondering about is how one might go about encoding the client mount point in the handle in v4. In v2-v3 there is a mount protocol so the mount daemon knows what you're mounting and can give you an appropriate root handle, including inforamtion encoding the client mount point. Further lookups can propagate the mount point information when handles are generated given the mount point information already in the directory handle. In v4, you start out with a public filehandle, get root file handle and then do more looks to get to your mount point. Is that right? So how does the server get a chance to encode your mount point in a handle? What am I missing here?
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:04 AM Z CST