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

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 10 Oct 2006 10:27:35 -0700

My knowledge of how Windows does this is incomplete,
but based on what I do know, this seems consistent
with it.  I don't know how Windows handles the
server reboot issue [witty comment elided].

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================  

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Tuesday, October 10, 2006 10:11 AM
> To: Mike Eisler
> Cc: [email-masked]
> Subject: Re: [nfsv4] Issue 122 Allow clients and servers to 
> negotiate away the.nfsjunkXXX file
> 
> 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
> 

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