Subject: Re: [nfsv4] Issue 122 Allow clients and servers to negotiate away the .nfsjunkXXX file

From: Spencer Shepler <[email-masked]>
Date: Tue, 10 Oct 2006 12:11:20 -0500

On Mon, Mike Eisler wrote:
> When a process goes to unlink an open file, many NFS
> client implementations will rename the open file to
> somthing like ".nfsjunkXXX" where XXX is some random or
> unique value.
> 
> This still causes problems. The typical use case is 
> a user attempting to remove a tree of stuff with the UNIX
> command:
>    rm -rf
> 
> No matter what the user does, the directory containing the
> file won't go away, and any ancestor directories won't go away
> either.
> 
> NFSv4 has an OPEN operation, and thus a reference hold
> from the client to the server on regular files. Thus, in principle,
> there's little preventing a client from removing the file, and
> nothing preventing the server from keeping the file from being
> removed until all clients have closed it, and all processes on the
> server have closed it. The only thing preventing it is a
> contract from the server to the client that it till
> maintain this behavior.
> 
> I propose that we add a per-filesystem boolean attribute,
> REMOVE_ON_LAST_CLOSE, that if true, tells the client the server
> will delay removal of the final hard link to a file
> until the last close. 
> 
> Implementing this isn't hard, as long as the server doesn't
> reboot. There's at least one relatively easy approach for
> the server to recover from server reboot. Instead of
> unlinking the file from the directory (if the hard link count is
> 1 and would go to zero), the server can instead
> rename the file to another directory (similar to the lost+found
> directory) in the file system. If the server crashes, then upon reboot
> it enters the grace period as before, and if the client reclaims the
> OPEN on the "removed" file, the server marks the file in
> the directory of removed but open files as recovered and open.
> At the end of the grace period, the server is free to remove
> any files in the directory that of removed but open files that
> haven't been recovered. The server could always defer removal
> until disk space considerations force its hand.

This seems reasonable, Mike.

I assume that you are building on the added feature of OPEN by filehandle
to deal with the other set of recovery issues?

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4