From: J. Bruce Fields Date: Fri, 15 Jul 2011 23:09:08 +0000 (-0400) Subject: nfs: document nfsv4 sillyrename issues X-Git-Tag: firefly_0821_release~3680^2~4795^2~39 X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=674e405b8b3310702fd43d314f5f432ec2cb9980;p=firefly-linux-kernel-4.4.55.git nfs: document nfsv4 sillyrename issues 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 Signed-off-by: Trond Myklebust --- diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c index 8d6864c2a5fa..981298ce5124 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)