On Tue, Aug 30, 2022 at 09:50:02AM -0400, Jeff Layton wrote:

On Tue, 2022-08-30 at 09:24 -0400, J. Bruce Fields wrote:

quoted

On Tue, Aug 30, 2022 at 07:40:02AM -0400, Jeff Layton wrote:

quoted

Yes, saying only that it must be different is intentional. What we
really want is for consumers to treat this as an opaque value for the
most part [1]. Therefore an implementation based on hashing would
conform to the spec, I'd think, as long as all of the relevant info is
part of the hash.

It'd conform, but it might not be as useful as an increasing value.

E.g. a client can use that to work out which of a series of reordered
write replies is the most recent, and I seem to recall that can prevent
unnecessary invalidations in some cases.

That's a good point; the linux client does this. That said, NFSv4 has a
way for the server to advertise its change attribute behavior [1]
(though nfsd hasn't implemented this yet).

It was implemented and reverted.  The issue was that I thought nfsd
should mix in the ctime to prevent the change attribute going backwards
on reboot (see fs/nfsd/nfsfh.h:nfsd4_change_attribute()), but Trond was
concerned about the possibility of time going backwards.  See
1631087ba872 "Revert "nfsd4: support change_attr_type attribute"".
There's some mailing list discussion to that I'm not turning up right
now.

Did NFSv4 add change_attr_type because some implementations needed the
unordered case, or because they realized ordering was useful but wanted
to keep backwards compatibility?  I don't know which it was.

--b.

We don't have a good way to
do that in userland for now.

This is another place where fsinfo() would have been nice to have. I
think until we have something like that, we'd want to keep our promises
to userland to a minimum.

[1]: https://www.rfc-editor.org/rfc/rfc7862.html#section-12.2.3 . I
guess I should look at plumbing this in for IS_I_VERSION inodes...

-- 
Jeff Layton [off-list ref]