On Mon, 2023-05-15 at 18:53 -0400, Jeff Layton wrote: > > Isn't CB_GETATTR the main benefit of a write delegation in the first > place? A write deleg doesn't really give any benefit otherwise, as > you > can buffer writes anyway without one. > > AIUI, the point of a write delegation is to allow other clients (and > potentially the server) to get up to date information on file sizes > and > change attr when there is a single, active writer. > > Without CB_GETATTR, your first stat() against the file will give you > fairly up to date info (since you'll have to recall the delegation), > but > then you'll be back to the server just reporting the size and change > attr that it has at the time. > The only advantage of CB_GETATTR is that it allows you to determine whether or not the client holding the delegation is also holding cached writes. Since we pretty much always rely on close-to-open semantics anyway, the benefit of implementing it is pretty marginal. Personally, I see CB_GETATTR as being more useful once servers start implementing the timestamp/attribute delegations as per https://datatracker.ietf.org/doc/draft-ietf-nfsv4-delstid/ ; Since those delegations allow the client to be authoritative for the atime and mtime timestamps, and to also cache those, then CB_GETATTR becomes a necessity in order to correctly timestamp writes that have already been committed to the file. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
