From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xin Zhao" Subject: Re: Urgent help needed on an NFS question, please help!!! Date: Thu, 10 Aug 2006 12:23:12 -0400 Message-ID: <4ae3c140608100923j1ffb5bb5qa776bff79365874c@mail.gmail.com> References: <4ae3c140608092204n1c07152k52010a10e209bb77@mail.gmail.com> <17626.49136.384370.284757@cse.unsw.edu.au> <4ae3c140608092254k62dce9at2e8cdcc9ae7a6d9f@mail.gmail.com> <17626.52269.828274.831029@cse.unsw.edu.au> <4ae3c140608100815p57c0378kfd316a482738ee83@mail.gmail.com> <20060810161107.GC4379@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Neil Brown" , linux-kernel , linux-fsdevel@vger.kernel.org Return-path: Received: from py-out-1112.google.com ([64.233.166.178]:9057 "EHLO py-out-1112.google.com") by vger.kernel.org with ESMTP id S1161424AbWHJQXO (ORCPT ); Thu, 10 Aug 2006 12:23:14 -0400 Received: by py-out-1112.google.com with SMTP id z74so894897pyg for ; Thu, 10 Aug 2006 09:23:13 -0700 (PDT) To: "Matthew Wilcox" In-Reply-To: <20060810161107.GC4379@parisc-linux.org> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org That makes sense. Can we make the following two conclusions? 1. In a single machine, inode+dev ID+i_generation can uniquely identify a file 2. Given a stored file handle and an inode object received from the server, an NFS client can safely determine whether this inode corresponds to the file handle by checking the inode+dev+i_generation. Thanks, -x On 8/10/06, Matthew Wilcox wrote: > On Thu, Aug 10, 2006 at 11:15:57AM -0400, Xin Zhao wrote: > > I am considering another possibility: suppose client C1 does lookup() > > on file X and gets a file handle, which include inode number, > > generation number and parent's inode number. Before C1 issues > > getattr(), C2 move the parent directory to a different place, which > > will not change the parent's inode number, neither the file X's inode, > > i_generation. So when C1 issues a getattr() request with this file > > handle, the server seems to have no way to detect that file X is not > > existent at the original path. Instead, the server will returns the > > moved X's attributes, which are correct, but semantically wrong. Is > > there any way that server deal with this problem? > > It isn't semantically wrong. There is no way for the application to > distinguish between the events: > > open() > stat() > mv > > and > > open() > mv > stat() > > As long as the results are consistent with the former case, it doesn't > matter if the latter case actually happened. >