On Thu, 2024-09-05 at 15:11 +0300, Roi Azarzar wrote: > Hi Jeff, > > We are working on implementing time proxying and it seems like there is some small inconsistency with the draft-ietf-nfsv4-delstid-02 and the latest implementation. > > In the draft I can see the following sentence: > If a server informs the client via the FATTR4_OPEN_ARGUMENTS attribute that it supports OPEN_ARGS_SHARE_ACCESS_WANT_DELEG_TIMESTAMPS. > > But in the suggested upstream implementation I can see the capability is derived from TIME_DELEG_MODIFY (using get attr FATTR4_SUPPORTED_ATTRS?): > if (res.attr_bitmask[2] & FATTR4_WORD2_TIME_DELEG_MODIFY) server->caps |= NFS_CAP_DELEGTIME; > > > I expected NFS_CAP_DELEGTIME to be set if the server sets OPEN_ARGS_SHARE_ACCESS_WANT_DELEG_TIMESTAMPS in FATTR4_OPEN_ARGUMENTS. > > Can you explain what is the right approach? > (cc'ing the linux-nfs mailing list, since I think this is relevant there) Probably not, because I'm not sure myself! To be clear, that's how the client is deciding whether to try to use delegated timestamps, so this is more about the client than the server. I also got bitten by this in testing, and worked around it by setting FATTR4_TIME_DELEG_MODIFY in supported attrs. I intended to go back and look at whether we should change that, but haven't had the chance. Should attributes that I can't query in a GETATTR be represented in supported attrs? I suppose it doesn't hurt, but it's not clear that it's expected, since the spec doesn't mention it. My guess is that this is a client bug, or (more likely) a holdover from an earlier version of the spec. Changing it to look at the results of FATTR4_OPEN_ARGUMENTS instead is probably the right thing to do. Care to propose a patch? -- Jeff Layton <jlayton@xxxxxxxxxx>
