[Bug 270842] nfsclient sees out-of-date metadata until stat(1)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270842

--- Comment #6 from Rick Macklem <rmacklem@FreeBSD.org> ---
Well, the default value for acregmax is 60sec.
(You can see what they are for any mount by doing
"nfsstat -m" on the NFS client.)

Then note that stat(2) and fstat(2) are two very different
stories.
For stat(2):
- There is a lookup. If there is a miss on the name cache,
  then this will result in a Lookup RPC, which has up-to-date
  attributes in the reply.
  --> So, I suppose you could consider the fact that it might
      do a Lookup RPC magical, then that might be the magic.

For fstat(2), there is no lookup, so it is going to return
cached (possibly stale) attributes until the attribute cache
times out (which could take up to acregmax seconds).

The NFS client does implement close->open consistency, which
means "once a file is close(2)'s on one client and then open(2)'d
on another client after the close(2) (in a temporal sense), the
client that does the open(2) should see all changes done by the
first client before it close(2)'d the file".
(This is actually approximately done, based on the NFS server's
time resolution for mtime for the file.)

I have no idea what "git" or "cargo" do, but if it happens to be
fstat(2) and not stat(2), you can see from the above why the
semantics would be different.

-- 
You are receiving this mail because:
You are the assignee for the bug.