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@xxxxxxxxxxxxxxx
