Subject: change of persistent_fh attribute

From: Spencer Shepler <[email-masked]>
Date: Thu, 04 Nov 1999 13:36:49 -0600

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)

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).

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.

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: Mike Eisler <[email-masked]>
Date: Thu, 4 Nov 1999 13:28:20 -0800 (PST)

I've e-mailed to Spencer a somewhat simpler defintion of the attribute that
implements the same semantic. I did want to make two points on the entire
alias though

FH4_STICKY_WITH_OPEN 
FH4_PERSIST_WITH_OPEN

The attribute should tell if a file handle will be preserved while the
is open. How the server ensures that seems outside the scope of the attribute.
If we want the information, it should be a separate attribute.

As a server implementor I might be able to tell the client how I'm preserving
the open ... consider a user-level server that lets the file system
deal with it.

Actually volatile "whenenver". While server restart is the classic reason for an
EXPIRE, it could be because the file handle was idle for several hours, and
so it got garbage collected. I don't think the client should care, it
just needs to know that the fh it got is extremely tenuous.

	-mre