On Tue, Aug 30, 2022 at 02:58:27PM +0000, Trond Myklebust wrote:

On Tue, 2022-08-30 at 10:44 -0400, J. Bruce Fields wrote:

quoted

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

quoted

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.

https://lore.kernel.org/linux-nfs/a6294c25cb5eb98193f609a52aa8f4b5d4e81279.camel@hammerspace.com/ (local)
is what I was thinking of but it isn't actually that interesting.

My main concern was that some filesystems (e.g. ext3) were failing to
provide sufficient timestamp resolution to actually label the resulting
'change attribute' as being updated monotonically. If the time stamp
doesn't change when the file data or metadata are changed, then the
client has to perform extra checks to try to figure out whether or not
its caches are up to date.

That's a different issue from the one you were raising in that
discussion.

quoted

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.

We implemented it because, as implied above, knowledge of whether or
not the change attribute behaves monotonically, or strictly
monotonically, enables a number of optimisations.

Of course, but my question was about the value of the old behavior, not
about the value of the monotonic behavior.

Put differently, if we could redesign the protocol from scratch would we
actually have included the option of non-monotonic behavior?

--b.