Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Dave Chinner" <david@fromorbit.com>
Cc:     "Jeff Layton" <jlayton@kernel.org>,
        "Mimi Zohar" <zohar@linux.ibm.com>, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org,
        linux-ext4@vger.kernel.org,
        "Trond Myklebust" <trondmy@hammerspace.com>
Subject: Re: [PATCH] iversion: update comments with info about atime updates
In-reply-to: <20220823232832.GQ3600936@dread.disaster.area>
References: <20220822133309.86005-1-jlayton@kernel.org>,
 <ceb8f09a4cb2de67f40604d03ee0c475feb3130a.camel@linux.ibm.com>,
 <f17b9d627703bee2a7b531a051461671648a9dbd.camel@kernel.org>,
 <18827b350fbf6719733fda814255ec20d6dcf00f.camel@linux.ibm.com>,
 <4cc84440d954c022d0235bf407a60da66a6ccc39.camel@kernel.org>,
 <20220822233231.GJ3600936@dread.disaster.area>,
 <6cbcb33d33613f50dd5e485ecbf6ce7e305f3d6f.camel@kernel.org>,
 <166125468756.23264.2859374883806269821@noble.neil.brown.name>,
 <df469d936b2e1c1a8c9c947896fa8a160f33b0e8.camel@kernel.org>,
 <166129348704.23264.10381335282721356873@noble.neil.brown.name>,
 <20220823232832.GQ3600936@dread.disaster.area>
Date:   Wed, 24 Aug 2022 09:42:18 +1000
Message-id: <166129813890.23264.7939069509747685028@noble.neil.brown.name>
Precedence: bulk

On Wed, 24 Aug 2022, Dave Chinner wrote:
> On Wed, Aug 24, 2022 at 08:24:47AM +1000, NeilBrown wrote:
> > On Tue, 23 Aug 2022, Jeff Layton wrote:
> > > On Tue, 2022-08-23 at 21:38 +1000, NeilBrown wrote:
> > > > On Tue, 23 Aug 2022, Jeff Layton wrote:
> > > > > So, we can refer to that and simply say:
> > > > >=20
> > > > > "If the function updates the mtime or ctime on the inode, then the
> > > > > i_version should be incremented. If only the atime is being updated,
> > > > > then the i_version should not be incremented. The exception to this=
 rule
> > > > > is explicit atime updates via utimes() or similar mechanism, which
> > > > > should result in the i_version being incremented."
> > > >=20
> > > > Is that exception needed?  utimes() updates ctime.
> > > >=20
> > > > https://man7.org/linux/man-pages/man2/utimes.2.html
> > > >=20
> > > > doesn't say that, but
> > > >=20
> > > > https://pubs.opengroup.org/onlinepubs/007904875/functions/utimes.html
> > > >=20
> > > > does, as does the code.
> > > >=20
> > >=20
> > > Oh, good point! I think we can leave that out. Even better!
> >=20
> > Further, implicit mtime updates (file_update_time()) also update ctime.
> > So all you need is
> >    If the function updates the ctime, then i_version should be
> >    incremented.
> >=20
> > and I have to ask - why not just use the ctime?  Why have another number
> > that is parallel?
> >=20
> > Timestamps are updated at HZ (ktime_get_course) which is at most every
> > millisecond.
>=20
> Kernel time, and therefore timestamps, can go backwards.

Yes, and when that happens you get to keep both halves...

For NFSv4 I really don't think that matters.  If it happened every day,
that might be a problem.  Even if it happens as a consequence of normal
operations it might be a problem.  But it can only happen if something
goes wrong.

Mostly, NFSv4 only needs to changeid to change.  If the kernel time goes
backwards it is possible that a changeid will repeat, though unlikely.
It is even possible that a client will see the first and second
instances of that repeat, and assume there is no change in between - but
that is astronomically unlikely.  "touch"ing the file or remounting will
fix that.

When a write delegation is in force (which Linux doesn't currently offer
and no-one seems to care about, but maybe one day), the client is
allowed to update the changeid, and when the delegation is returned, the
server is supposed to ensure the new changeid is at least the last one
assigned by the client.  This is the only reason that it is defined as
being monotonic (rather than just "non-repeating") - so the client and
server can change it in the same way.

So while kernel time going backwards is theoretically less than ideal,
it is not practically a problem.

NeilBrown