Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750849AbWL2K3Y (ORCPT ); Fri, 29 Dec 2006 05:29:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750994AbWL2K3Y (ORCPT ); Fri, 29 Dec 2006 05:29:24 -0500 Received: from pat.uio.no ([129.240.10.15]:39827 "EHLO pat.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbWL2K3X (ORCPT ); Fri, 29 Dec 2006 05:29:23 -0500 Subject: Re: [nfsv4] RE: Finding hardlinks From: Trond Myklebust To: "Halevy, Benny" Cc: Mikulas Patocka , Jan Harkes , Miklos Szeredi , linux-kernel@vger.kernel.org, nfsv4@ietf.org, linux-fsdevel@vger.kernel.org, Jeff Layton , Arjan van de Ven In-Reply-To: References: <20061221185850.GA16807@delft.aura.cs.cmu.edu> <1166869106.3281.587.camel@laptopd505.fenrus.org> <4593890C.8030207@panasas.com> <4593C524.8070209@poochiereds.net> <4593DEF8.5020609@panasas.com> Content-Type: text/plain Date: Fri, 29 Dec 2006 11:28:49 +0100 Message-Id: <1167388129.6106.45.camel@lade.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=12.0, autolearn=failed, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: BDB21F42809B1EB74B04066B4164AA29E4350D1B X-UiO-SPAM-Test: 83.109.147.16 spam_score -49 maxlevel 200 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1947 Lines: 41 On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote: > Mikulas Patocka wrote: > >BTW. how does (or how should?) NFS client deal with cache coherency if > >filehandles for the same file differ? > > > > Trond can probably answer this better than me... > As I read it, currently the nfs client matches both the fileid and the > filehandle (in nfs_find_actor). This means that different filehandles > for the same file would result in different inodes :(. > Strictly following the nfs protocol, comparing only the fileid should > be enough IF fileids are indeed unique within the filesystem. > Comparing the filehandle works as a workaround when the exported filesystem > (or the nfs server) violates that. From a user stand point I think that > this should be configurable, probably per mount point. Matching files by fileid instead of filehandle is a lot more trouble since fileids may be reused after a file has been deleted. Every time you look up a file, and get a new filehandle for the same fileid, you would at the very least have to do another GETATTR using one of the 'old' filehandles in order to ensure that the file is the same object as the one you have cached. Then there is the issue of what to do when you open(), read() or write() to the file: which filehandle do you use, are the access permissions the same for all filehandles, ... All in all, much pain for little or no gain. Most servers therefore take great pains to ensure that clients can use filehandles to identify inodes. The exceptions tend to be broken in other ways (Note: knfsd without the no_subtree_check option is one of these exceptions - it can break in the case of cross-directory renames). Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/