Subject: RE: change of persistent_fh attribute

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 4 Nov 1999 12:26:50 -0800

> Based on some suggestions from Neil Brown, I am proposing to make
> the following types of changes to the I-D.  Note that this does
> not incorporate Neil's suggestion of using GETATTR('filehandle') as
> a method to recover from receipt of NFS4ERR_FHEXPIRED.  Path name
> recovery is still the model with respect to the following changes.
> 
> ----
> 
> Change 'persistent_fh' attribute to:
> 
> 
> 
> fh_expire_type	2	uint32	READ	Server uses 
> this to specify
> 					filehandle expiration behavior
> 					to the client.
> 
> 
> const	FH4_PERSISTENT		= 0x00000000;
> const	FH4_VOLATILE		= 0x00000001;
> const	FH4_VOL_AT_RESTART	= 0x00000002;
> const	FH4_VOL_AT_MIGRATION	= 0x00000004;
> const	FH4_VOL_AT_RENAME	= 0x00000008;
> const	FH4_STICKY_WITH_OPEN	= 0x00000010;
> const	FH4_PERSIST_WITH_OPEN	= 0x00000020;
> 
> 
> 
> FH4_PERSISTENT - fh is valid until object is removed
> 
> FH4_VOLATILE - server may return EXPIRED at any time during use
> 
> (rest are modifiers for VOLATILE)

Shouldn't there be some way to specify that handles are volatile
but will only expire as indicated by FH4_VOL_AT_* (i.e. at no 
other times)?  How about FH4_VOL_AT_OTHERS for negation of that 
and then define FH4_VOLATILE as FH4_VOL_AT_OTHERS | 
FH4_VOL_AT_RESTART | FH4_VOL_AT_MIGRATION | FH4_VOL_AT_RENAME.

Or are you saying that filehandles may not expire at any
other times, that the list is exhaustive?

> 
> FH4_VOL_AT_RESTART - filehandles will EXPIRE when server restarts
> 
> FH4_VOL_AT_MIGRATION - filehandles will EXPIRE when filesystem is
> migrated
> 
> FH4_VOL_AT_RENAME - filehandles will EXPIRE when rename
> 
> FH4_STICKY_WITH_OPEN - filehandle will EXPIRE at server restart but if
> the file is OPEN, the server will deny RENAME and REMOVE of the open
> file.  Server will also deny RENAME and REMOVE during grace period to
> allow client the ability to recover by use of path name.
> 
> FH4_PERSIST_WITH_OPEN - filehandles will be persistent as long as file
> is OPEN (the server takes the appropriate steps to ensure the
> filehandle will not expire at rename, restart, or migration).

I assume that they will not be expired at any time while OPEN 
(this gets back to the issue of whether the list of rename, restart, 
migration is exhaustive).

Also, in the context, "will be persistent" is confusing since
they are volatile.  How about "will remain valid"?

> 
> 
> Servers that use volatile filehandles should deny the RENAME or REMOVE
> of a file while it is OPEN and should deny all RENAME or REMOVE
> requests during the grace period upon restart.

In this paragraph, it is unclear whether a rename of directory
that ultimately includes an OPEN file is intended to be 
included.

> 
> 
> With the above set, the client should be able to anticipate the type
> of recovery method needed when it receives a NFS4ERR_FHEXPIRED error.
>

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 04 Nov 1999 14:35:15 -0600

> other times, that the list is exhaustive?

What I attempted to capture was all of the events that an expiration
could occur that would effect the way a client would be implemented.
A server could have volatile file handles but they only expire
when a file is RENAMEd or only when the server RESTARTs.

> migration is exhaustive).

Right, will not expire at any time.  I will add an "i.e." prior
to the list.

> they are volatile.  How about "will remain valid"?

How about 'will not expire' instead.

> that ultimately includes an OPEN file is intended to be

Good point.  I will clarify it by including the components leading
to the file.