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

From: Mike Eisler <[email-masked]>
Date: Mon, 18 Sep 2006 09:45:05 -0700 (PDT)

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.

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