> On Jul 3, 2023, at 5:33 PM, NeilBrown <neilb@xxxxxxx> wrote: > > On Mon, 03 Jul 2023, Chuck Lever III wrote: >> >> - It's not the efficiency of encode_fattr() that is the issue, >> it's the frequency of its use. That's something the server >> can't do much about. > > There probably needs a protocol revision to improve this. I imagine a > GETATTR request including a CTIME value with the implication that if the > CTIME hasn't changed, then there is no need to return any attributes. You can precede the GETATTR with an NVERIFY operation. https://datatracker.ietf.org/doc/html/rfc8881#name-operation-17-nverify-verify -- Chuck Lever