From: Mike Eisler (mre@eng.sun.com)
Date: 10/14/99-06:36:55 AM Z
Date: Thu, 14 Oct 1999 04:36:55 -0700 (PDT) From: Mike Eisler <mre@eng.sun.com> Subject: Re: Feedback on draft-ietf-nfsv4-01 - volatile file handles Message-ID: <Roam.SIMC.2.0.6.939901015.9577.mre@eng.sun.com> > Having thought more about it, I don't think that "persistent" as it > stands is particularly necessary. > Consider the following: > Any access with any filehandle may return NFS4ERR_FHEXPIRED > except: > GETATTR(persistent_fh) > > If GETATTR(persistent_fh) returns "persistent", then > GETATTR(filehandle) WILL return a new filehandle that can be used > on the file. If a GETATTR on the old file handle works to return a new file handle, then why do we need a new file handle? FHEXPIRED ca't be returned on a filehandle with the persistent attribute, otherwise it isn't persistent. > If GETATTR(persistent_fh) returns "path_safe", then an appropriate > series of LOOKUPs should be used to find the new filehandle. > If GETATTR(persistent_fh) returns "open_safe", then either: > GETATTR(filehandle) will return a valid handle for the file > or > the server didn't think you have the file open (and hopefully > the client didn't either), so this filehandle is simply a > cached copy which is no-longer valid, and the client should > act as though it didn't have a cached filehandle. (Actually, > the server could probably have returned NFS4ERR_STALE in this > case). > > Providing GETATTR(persistent_fh) is not "none", the client has a > guaranteed way to deal with NFS4ERR_FHEXPIRED. > > If GETATTR(persistent_fh) returns "none", then the client has NO > guarantees about continued access to the file. The server may in > some instances honour GETATTR(filehandle) after an > NFS4ERR_FHEXPIRED, but the client should probably call > GETATTR(filehandle) on a regular basis, just in case, on the > assumption that the server might cache changes, but for limited time. Aside from the persistent_fh definition, your suggestion is a reasonable step toward moving forward with the never ending debate around volatile file handles. If open_safe is true, and persistent_fh and path_safe are false, then the server, even through server reboot/recovery, will ensure that the file handle returned by open is valid as long as the file is open. The file handle is indeed volatile, but there are no risks if there is an attempt to rename or unlink the file by the client or another client. Either the rename or unlink will be denied, or the server will record in stable storage, some state that allows it to recover the file handle to file mapping after a server reboot. This allows a server to return volastile file handles from writeable file systems. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:43 AM Z CST