Re: Does NFSv4 close-to-open consistency work with server "async" mount open?

[Trond Myklebust <trondmy@hammerspace.com>]

On Thu, 2023-11-16 at 07:30 -0500, Benjamin Coddington wrote:
> On 16 Nov 2023, at 2:11, Martin Wege wrote:
> 
> > Hello,
> > 
> > Does NFSv4 close-to-open consistency on the client work with server
> > "async" mount open?
> 
> Yes, I believe it should, but I am looking at knfsd code and I think
> it
> won't.
> 
> > We see several build errors here with parallel GNU Makefile update,
> > where one process writes a file, exists, and the next process
> > doesn't
> > see all data (linker ar: file too short).
> > But if you manually look at it the files are OK, and completely
> > written.

If the process doing the checking is running on the same one that wrote
the file, then we should be able to emulate full POSIX semantics, and
your problem is not NFS related.

If the two processes are running on different clients, then the caching
issues come into play. If that is the case, then is the linker opening
the file, or is it just using stat()? If the latter, then it is not
relying on close-to-open cache consistency, but just standard attribute
caching (i.e. polling).

> > 
> > What is this? NFSv4 client bug, NFSv4 server bug, admin error
> > (async
> > breaking close-to-open consistency?
> 
> Hard to say, a wire capture would show.  My guess is that the
> server's
> "async" disables the write gather in nfsd_vfs_write().


The "async" flag in /etc/exports disables COMMIT and metadata commits.
IOW: it is a data persistence threat, but does not change any caching
semantics.

> > Also, is close-to-open consistency guaranteed between different
> > NFSv4 clients?
> 
> Yes.
> 
> Ben
> 

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com