On Tue, 2020-12-01 at 10:19 -0500, bfields@xxxxxxxxxxxx wrote: > On Tue, Dec 01, 2020 at 03:23:00AM +0000, Trond Myklebust wrote: > > On Tue, 2020-12-01 at 03:16 +0000, Trond Myklebust wrote: > > > On Mon, 2020-11-30 at 22:11 -0500, bfields@xxxxxxxxxxxx wrote: > > > > On Tue, Dec 01, 2020 at 03:06:46AM +0000, Trond Myklebust > > > > wrote: > > > > > A local filesystem might choose to set the 'non-atomic' flag > > > > > without > > > > > wanting to turn off NFSv3 WCC attributes. Yes, the latter are > > > > > assumed > > > > > to be atomic, but a number of commercial servers do abuse > > > > > that > > > > > assumption in practice. > > > > > > > > What do you mean by abusing that assumption? > > > > > > > > I thought that leaving off the post-op attrs was the v3 > > > > protocol's > > > > way > > > > of saying that it couldn't give you atomic wcc information. > > > > > > > > > > I mean that a number of commercial servers will happily return > > > NFSv3 > > > pre/post-operation WCC information that is not atomic with the > > > operation that is supposed to be 'protected'. This is, after all, > > > why > > > the NFSv4 "struct change_info4" added the 'atomic' field in the > > > first > > > place. > > > > BTW: To be fair, so does knfsd... > > > > At Hammerspace, we had some real problems recently due to XFS > > exports > > returning non-atomic values for the "space used" field. Speculative > > preallocation is a real bitch: > > https://xfs.org/index.php/XFS_FAQ#Q:_What_is_speculative_preallocation.3F > > So you think xfs should omit v3 post-operation attributes and still > set > the atomic bit in v4 replies? > > Would that have helped in the cases you saw? It seems like > speculative > preallocation isn't a problem with atomicity exactly--it couldn't be > avoided by applications cooperating with some locking scheme, for > example, if I'm understanding right. > Locking doesn't help. This isn't even something that needs multiple clients. XFS will happily give the client that sends the WRITE one answer for 'space used' in the WCC attributes, and then a different answer in a subsequent GETATTR (no change in mtime, ctime or change attribute) once the speculative allocation has been resolved. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx