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. --b.
