Subject: Re: .nfsXXXX files

From: Mike Eisler <[email-masked]>
Date: Thu, 22 Mar 2001 14:29:10 -0800 (PST)

> To this point, we have added state to the NFSv4 server but have done
> it in such a way that the server is not required to store more state
> than can be normally represented in the target file system.  Locking
> state, open state, delegation state, will be reclaimed by the client
> when a server restarts.  As an optimization the server can store
> additional state for faster recovery.
> 
> To remove the need for the client to rename a file to .nfsXXXX when a
> client removes the file and that file is open, the server will need to
> move that file to another location in the file system itself or
> effectively hide it from the clients.  If the server fails, the server
> will now have to find and deal with these removed but accessible files
> as part of its recovery procedure.  This type of state recovery is a
> departure from the current model and seems difficult to provide
> consistently amongst a set of disparate file systems at the server.

Good points.

I think if a server allows an open file to be removed, and then allows
that file to be accessed after the remove, then it MUST implement the
capability to recover that file if the server reboots while the file is
open. Conversely if it cannot recover such files, then I think it must
refuse the remove, or if it allows the remove, return NFS4ERR_STALE on
subsequent accesses  This ought to be part of the v4.0 specification.
This way, clients that test for the following,

	- can open files can be removed, AND
	- can open files be accessed after the removal,
	
can then avoid .nfsXXXX.  Maybe these tests should instead be
should be attributes, but it doesn't matter to me if the attribute is
added after v4.0.

	-mre