On Tue, 2021-11-16 at 09:12 -0500, Benjamin Coddington wrote: > On 16 Nov 2021, at 9:03, Trond Myklebust wrote: > > No, we really shouldn't need to care what the server thinks or > > does. > > The client is authoritative for the change attribute while it holds > > a > > delegation, not the server. > > My understanding of the intention of the code (which I had to sort of > put > together from historical patches in this area) is that we want to see > ctime, > mtime, and block size updates after copy/clone even if we hold a > delegation, > but without NFS_INO_INVALID_CHANGE, the client won't update those > attributes. > > If that's not necessary, we can drop this patch. > We will still see the ctime/mtime/block size updates even if NFS_INO_INVALID_CHANGE is not set. Those attributes' cache status are tracked separately through their own NFS_INO_INVALID_* bits. That said, there really is no reason why we shouldn't treat the copy and clone code exactly the same way we would treat a regular write. Perhaps we can fix up the arguments of nfs_writeback_update_inode() so that it can be called here? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
