On Thu, Oct 01, 2020 at 07:29:51PM +0000, Trond Myklebust wrote: > On Thu, 2020-10-01 at 15:26 -0400, bfields@xxxxxxxxxxxx wrote: > > On Thu, Oct 01, 2020 at 07:24:42PM +0000, Trond Myklebust wrote: > > > NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR should normally be good enough > > > to > > > allow the above optimisation, yes. I'm less sure about whether or > > > not > > > we are correct in returning NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR when > > > in > > > fact we are adding the ctime and filesystem-specific change > > > attribute, > > > but we could fix that too. > > > > Could you explain your concern? > > > > Same as before: that the ctime could cause the value to regress if > someone messes with the system time on the server. Yes, we do add in > the change attribute, but the value of ctime.tv_sec dominates by a > factor 2^30. Got it. I'd like to just tell people not to do that.... If we think it's too easy a mistake to make, I can think of other approaches, though filesystem assistance might be required: - Ideal would be just never to expose uncommitted change attributes to the client. Absent persistant RAM that could be terribly expensive. - It would help just to have any number that's guaranteed to increase after a boot. Of course, if would to go forward at least as reliably as the system time. We'd put it in the high bits of the on-disk i_version. (We'd rather not just mix it into the returned change attribute as we do with ctime, because that would cause clients to discard all their caches unnecessarily after boot.) --b.
