Skip to content

Commit

Permalink
nfs: document nfsv4 sillyrename issues
Browse files Browse the repository at this point in the history
Somebody working on this code asked what the deal was with NFSv4, since
this comment notes that it's v2/v3's statelessness that requires
sillyrename.  Shouldn't hurt to document the answer.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
  • Loading branch information
J. Bruce Fields authored and Trond Myklebust committed Jul 15, 2011
1 parent 94b134a commit 674e405
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions fs/nfs/unlink.c
Original file line number Diff line number Diff line change
Expand Up @@ -501,6 +501,14 @@ nfs_async_rename(struct inode *old_dir, struct inode *new_dir,
* and only performs the unlink once the last reference to it is put.
*
* The final cleanup is done during dentry_iput.
*
* (Note: NFSv4 is stateful, and has opens, so in theory an NFSv4 server
* could take responsibility for keeping open files referenced. The server
* would also need to ensure that opened-but-deleted files were kept over
* reboots. However, we may not assume a server does so. (RFC 5661
* does provide an OPEN4_RESULT_PRESERVE_UNLINKED flag that a server can
* use to advertise that it does this; some day we may take advantage of
* it.))
*/
int
nfs_sillyrename(struct inode *dir, struct dentry *dentry)
Expand Down

0 comments on commit 674e405

Please sign in to comment.