NFS consistency problem?

[Mike Eisler]

> > thanks for your suggestion.
> > 
> > I tried and now my options are:
> >
sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534
> > 
> > (afterwards exportfs -r and a remount at the client side)
> > 
> > It still happens:
> > 
> > I log onto computer A as user X, onto computer B as the same 
> > user X. Now, at 
> > the bash prompt I type
> >   echo A >> file.txt
> > on computer A, afterwards
> >   echo B >> file.txt
> > on computer B and so on.
> > 
> > cat file.txt gives me
> >   A
> >   A
> >   A
> > 
> > So, A did not get notified about the changes, B made.
> > 
> > And, by the way, shouldn't async still guarantee coherency?
> > 
> 
> Jonathan,
> 
> As suggested by Trond Myklebust, you should read faq a8 on 
> sourceforge.net. There's a few mount options you can try to

That faq entry talks about close-to-open consistency. The sequence,

   echo A >> file.txt
              on computer A, afterwards
   echo B >> file.txt
             on computer B and so on.
cat file.txt gives me
   A
   A
   A

looks to me like one that close-to-open consistency should support
(as long as each echo >> are serialized)

So why isn't Jonathan getting:
   A
   B
   A
   B
   A
   B

?

My guess is his NFSv4 server does not fully support the
"change" attribute. The FAQ entry says:

``Linux implements close-to-open cache consistency by comparing the
results of a GETATTR operation done just after the file is closed to
the results of a GETATTR operation done when the file is next opened.
If the results are the same, the client will assume its data cache is
still valid; otherwise, the cache is purged.''

and

``Be careful not to confuse "noac" with "no data caching." ''

If the NFSv4 server does not increment the "change" attribute on
each modification, then comparing the GETATTR results on open() with
that of the previous close() won't help, even with noac.

I've heard that ext3 does not support sub-second granularity for the
mtime and ctime attributes in NFSv3. Assuming the NFSv4 server on
Linux uses "ctime" to simulate "change", and assuming the "echo"
commands are done less than a second apart, this might explain the
problem.
> help maintain coherency.
> 
> Denis 
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>