-------- Original Message by Edgar --------
I was part of the discussion group for NFSv4 spec the short comings of v2 and v3 have been fixed
I'm a bit surprised by this. Which "discussion group"?
The RFC, one for NFSv4.0
NFSD (v2/v3) is stateless other than the information provided by mountd (mount requests) and lockd (file locking).
NFS is stateless save the state information remembered by statd. After all, that's the whole point of statd (and the NLM grace period).
NFS v2/v3 has no concept of locking so a external protocol was added, still keeping NFS v2/v3 stateless.
A long time ago FileSystemHandle would stay the same between reboots and you wouldn't get this problem other than on an individual file.
My XNFS says:
7.1.3 Stateless Servers and Idempotency
[...]
With a few exceptions, rebooting the server must not invalidate distributed state information.
(with the exceptions being unstable writes, teporary files etc.)
Yes the spec says this, and at first everyone implemented it this way, and then everyone changed it due to Security issues, maybe no-one went back and updated the spec. The FileSystemHandle (ie File Handle at the top of exported file system) is now changed on every-reboot, unless your in a Cluster configuration.
To handle deleted files which are in use by NFS clients some servers rename them to .nfs* because if one client deleted and other clients where accessing the file then they would get Stale NFS handle.
This rename takes place on the client on a REMOVE, not on the server. Cf. either McKusick et. al. or RFC 1813, 3.3.12, IMPLEMENTATION.
Bad sentence the client deletes the file, and if it is still in use at the time the client goes to delete it, it is renamed instead .nfsNNNN
Once in a while a NFS server will do find $dir -type f -name .nfs\* -mtime +7 -mount -exec rm -f {} \; to clean up.
Do you have any reference for that?
http://www.google.com.au/search?hl=en&q=%2Bfind+%22%2B-name+.nfs*%22+%2Brm+%2Bmtime http://www.google.com.au/search?hl=en&q=nfsfind #can be found in shell scripts e.g. nfsfind Look at your crontabs on your nfs server. The above find and remove .nfs files on a server is a cleanup, e.g. client crashes before a in-use file is deleted
If you do not get the Stale File Handle error when the server reboots, it most likely means the FileSystemHandle is not changing between reboots
I.e., it conforms to the specs.
The specs had problems
but then you may have more security issues.
Could you please elaborate on this "secutity issues"?
NFSD (v2/3) is stateless and trusts the security information (UDP, RPC requests using AUTH_UNIX) from the NFS client . The client is effectively responsible for the security when talking to a NFSv2/3 client. (NFSv4 does too (the default is AUTH_SYS,AUTH_UNIX) unless you setup the security to use RPCSEC_GSS or AUTH_DH). The first step taken by a NFSv2/3 client is to get the FileHandle for an exported path from mountd which checks the access lists for the NFS share, this FileHandle is used to talk to NFSD for the top of the export/shared path.
Cheers.