Re: NFS sillyrename side effect

[Jeff Layton <jlayton@redhat.com>]

On Mon, 18 Oct 2010 15:53:44 +0100
Cláudio Martins <ctpm@ist.utl.pt> wrote:

> 
> On Mon, 18 Oct 2010 15:48:11 +0100 Cláudio Martins <ctpm@ist.utl.pt> wrote:
> > 
> >  Section D2 ends with:
> > 
> > "The NFS version 4 protocol is stateful, and could actually support
> > delete-on-last-close. Unfortunately there isn't an easy way to do this
> > and remain backwards-compatible with version 2 and 3 accessors."
> > 
> >  So, theoretically, could one modify the code to selectively disable
> > silly rename on a client, when it knows it is talking v4 with the
> > server?
> > 
> 
>  BTW, to clarify, I'm assuming a scenario where the server is
> configured to talk v4 only, which I suspect should be common, at least
> when you're relying on v4 kerberos security.
> 

Sadly, no...

The server does generally hold the file open as long as the client has
the file open. So, you could delete the file while nfsd has it open and
everything would probably still work.

Suppose though that the server crashes and reboots. When it comes back
up, fsck figures out that the file has been unlinked and frees the
blocks on the disk. Now you can't reclaim the state on the open file.

We're pretty much stuck with silly-renaming even for v4.

-- 
Jeff Layton <jlayton@redhat.com>