From patchwork Fri Jul 15 23:09:08 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "J. Bruce Fields" X-Patchwork-Id: 980922 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p6FN9BrY010811 for ; Fri, 15 Jul 2011 23:09:12 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752357Ab1GOXJK (ORCPT ); Fri, 15 Jul 2011 19:09:10 -0400 Received: from fieldses.org ([174.143.236.118]:36604 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752051Ab1GOXJK (ORCPT ); Fri, 15 Jul 2011 19:09:10 -0400 Received: from bfields by fieldses.org with local (Exim 4.72) (envelope-from ) id 1QhrVM-0007VV-KS; Fri, 15 Jul 2011 19:09:08 -0400 Date: Fri, 15 Jul 2011 19:09:08 -0400 To: Trond Myklebust Cc: linux-nfs@vger.kernel.org Subject: [PATCH] nfs: document nfsv4 sillyrename issues Message-ID: <20110715230908.GD28012@fieldses.org> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) From: "J. Bruce Fields" Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Fri, 15 Jul 2011 23:09:12 +0000 (UTC) From: J. Bruce Fields 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 --- 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)