On 21.11.2007, at 15.56, Trond Myklebust wrote:
> 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.
With files it's possible to work around this limitation with fcntl
locking, but directories can't be locked. So back to my original
question: Would it be possible to have chmod(dir, (uid_t)-1,
(gid_t)-1) flush its cache? I don't see what harm there could be in
this, since normally no-one would do it anyway and the change is simple.
On Wed, 2007-11-21 at 22:36 +0200, Timo Sirainen wrote:
> On 21.11.2007, at 15.56, Trond Myklebust wrote:
>
> > 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.
>
> With files it's possible to work around this limitation with fcntl
> locking, but directories can't be locked. So back to my original
> question: Would it be possible to have chmod(dir, (uid_t)-1,
> (gid_t)-1) flush its cache? I don't see what harm there could be in
> this, since normally no-one would do it anyway and the change is simple.
I thought you said this was for flushing the attribute cache?
Flushing the attribute cache won't help in this case, since the crux of
the problem is that the attributes haven't actually changed at all.
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