From: "Xin Zhao" <uszhaoxin@gmail.com>
To: "Neil Brown" <neilb@suse.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: Urgent help needed on an NFS question, please help!!!
Date: Thu, 10 Aug 2006 11:15:57 -0400 [thread overview]
Message-ID: <4ae3c140608100815p57c0378kfd316a482738ee83@mail.gmail.com> (raw)
In-Reply-To: <17626.52269.828274.831029@cse.unsw.edu.au>
Hi,
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?
Thanks a lot!
-x
On 8/10/06, Neil Brown <neilb@suse.de> wrote:
> On Thursday August 10, uszhaoxin@gmail.com wrote:
> > Many thanks for your kind help!
> >
> > Your answer is what I expected. But what frustrated me is that I
> > cannot find the code that verifies the generation number in NFS V3
> > codes. Do you know where it check the generation number?
>
> NFSD doesn't. The individual filesystem does. You need to look in
> the filesystem code.
>
> Some filesystems use common code from fs/exportfs/expfs.c
> See "export_iget".
>
> NeilBrown.
>
next prev parent reply other threads:[~2006-08-10 15:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 5:04 Urgent help needed on an NFS question, please help!!! Xin Zhao
2006-08-10 5:11 ` Neil Brown
2006-08-10 5:54 ` Xin Zhao
2006-08-10 6:03 ` Neil Brown
2006-08-10 15:15 ` Xin Zhao [this message]
2006-08-10 16:11 ` Matthew Wilcox
2006-08-10 16:23 ` Xin Zhao
2006-08-10 16:54 ` Matthew Wilcox
2006-08-10 17:08 ` Xin Zhao
2006-08-10 17:38 ` Trond Myklebust
2006-08-10 17:28 ` Trond Myklebust
2006-08-10 18:02 ` Xin Zhao
2006-08-10 19:59 ` Trond Myklebust
2006-08-10 22:25 ` Xin Zhao
2006-08-11 0:44 ` Trond Myklebust
2006-08-10 22:28 ` Xin Zhao
2006-08-11 0:38 ` Trond Myklebust
2006-08-10 23:42 ` Bryan Henderson
2006-08-10 17:50 ` Bryan Henderson
2006-08-10 18:15 ` Xin Zhao
2006-08-11 0:07 ` Bryan Henderson
2006-08-10 21:00 ` Peter Staubach
2006-08-10 6:04 ` Xin Zhao
2006-08-10 6:15 ` Xin Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ae3c140608100815p57c0378kfd316a482738ee83@mail.gmail.com \
--to=uszhaoxin@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).