[Dovecot] I stream read - stale NFS file handle (reboot of server)

[Damon Atkins]

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