nfs: document nfsv4 sillyrename issues

PATCH New J. Bruce Fields 1 participant 1 message Jul 15, 2011

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

J. Bruce Fields

author

2011-07-15 23:09 UTC #0 lore raw

PATCH 1/1 nfs: document nfsv4 sillyrename issues

From: J. Bruce Fields <[email protected]>

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 <[email protected]>

---
 fs/nfs/unlink.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

fs/nfs/unlink.c +8 -0

index 8d6864c..981298c 100644
@@ -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)

Signature · 1 line

1.7.4.1