luck/tmp_suning_uos_patched
1
0
Fork 1
Code Issues Pull Requests Packages Projects Releases Wiki Activity

nfs: document nfsv4 sillyrename issues

Browse Source 
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>
This commit is contained in:
J. Bruce Fields 2011-07-15 19:09:08 -04:00 committed by Trond Myklebust
parent 94b134ac8e
commit 674e405b8b
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
fs/nfs/unlink.c
View File

@ -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)