On Tue, 2007-11-20 at 18:47 -0500, Trond Myklebust wrote:
> On Tue, 2007-11-20 at 04:14 +0200, Timo Sirainen wrote:
> > On Sun, 2007-11-18 at 00:11 +0200, Timo Sirainen wrote:
> > > > Why can't you simply close(), and then re-open() the file? That is _the_
> > > > standard way to force an attribute cache revalidation on all NFS
> > > > versions. The close-to-open caching model, which is implemented on most
> > > > NFS clients guarantees this.
> > ..
> > > close()+open() would have been difficult to handle because open() can
> > > fail, but looks like opening another file descriptor and closing it
> > > works just as well. Also looks like it works for flushing directories'
> > > attribute cache (which doesn't seem to work with FreeBSD though).
> >
> > Actually it works for flushing a directory's attribute cache in
> > v2.6.17-rc2, but not in v2.6.22. chown() works in v2.6.22 also. Is there
> > a reason for this change? I guess it anyway means that I'm back to using
> > chown() for flushing a directory's attribute cache.
>
> close-to-open caching works fine for me in v2.6.22. It does indeed send
> a GETATTR and revalidate the inode.
I don't have my own NFS test setup, so I can't check what actually
happens in the network, but I can easily reproduce this as a user:
1. touch foo.1 foo.2
2. Run on NFS client 1:
rm -f foo;ln foo.1 foo;sleep 0.5;rm -f foo;ln foo.2 foo
3. Run on NFS client 2 within that 0.5 secs:
echo *>/dev/null;stat foo;sleep 0.5;echo * >/dev/null;stat foo
After repeating this a few (2-5) times stat will return foo.1's inode
for both stats and running the command over and over again will return
only foo.1's inode. The only way to get NFS client 2 to notice the
change and return foo.2's inode is to either wait for attribute cache to
timeout or to run "chown 0 ."
Now that I think of it, I guess the reason is that my 2.6.22 setup has
Linux+ext3 as NFS server and 2.6.17-rc2 setup has NetApp as server. So
even though open()+close() flushes the directory's attribute cache, it
doesn't flush the file name -> NFS handle cache unless mtime changes?
On Wed, 2007-11-21 at 15:14 +0200, Timo Sirainen wrote:
> Now that I think of it, I guess the reason is that my 2.6.22 setup has
> Linux+ext3 as NFS server and 2.6.17-rc2 setup has NetApp as server. So
> even though open()+close() flushes the directory's attribute cache, it
> doesn't flush the file name -> NFS handle cache unless mtime changes?
Right. You're hitting the principal limitation of ext3 as an NFS backend
filesystem.
As I said in an earlier mail, the resolution on the time is 1 second, so
client 2 can basically not see any changes that happen within < 1 second
on client 1. The reason is that the mtime stays the same.
Cheers
Trond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs