* [PATCH] nfs: document nfsv4 sillyrename issues
@ 2011-07-15 23:09 J. Bruce Fields
0 siblings, 0 replies; only message in thread
From: J. Bruce Fields @ 2011-07-15 23:09 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs
From: J. Bruce Fields <bfields@redhat.com>
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>
---
fs/nfs/unlink.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 8d6864c..981298c 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -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)
--
1.7.4.1
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2011-07-15 23:09 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-15 23:09 [PATCH] nfs: document nfsv4 sillyrename issues J. Bruce Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).