Re: [man-pages RFC PATCH v4] statx, inode: document the new STATX_INO_VERSION field

[Trond Myklebust <trondmy@hammerspace.com>]

On Mon, 2022-09-12 at 09:51 -0400, J. Bruce Fields wrote:
> On Mon, Sep 12, 2022 at 08:55:04AM -0400, Jeff Layton wrote:
> > Because of the "seen" flag, we have a 63 bit counter to play with.
> > Could
> > we use a similar scheme to the one we use to handle when "jiffies"
> > wraps? Assume that we'd never compare two values that were more
> > than
> > 2^62 apart? We could add i_version_before/i_version_after macros to
> > make
> > it simple to handle this.
> 
> As far as I recall the protocol just assumes it can never wrap.  I
> guess
> you could add a new change_attr_type that works the way you describe.
> But without some new protocol clients aren't going to know what to do
> with a change attribute that wraps.
> 
> I think this just needs to be designed so that wrapping is impossible
> in
> any realistic scenario.  I feel like that's doable?
> 
> If we feel we have to catch that case, the only 100% correct behavior
> would probably be to make the filesystem readonly.
> 

Which protocol? If you're talking about basic NFSv4, it doesn't assume
anything about the change attribute and wrapping.

The NFSv4.2 protocol did introduce the optional attribute
'change_attr_type' that tries to describe the change attribute
behaviour to the client. It tells you if the behaviour is monotonically
increasing, but doesn't say anything about the behaviour when the
attribute value overflows.

That said, the Linux NFSv4.2 client, which uses that change_attr_type
attribute does deal with overflow by assuming standard uint64_t wrap
around rules. i.e. it assumes bit values > 63 are truncated, meaning
that the value obtained by incrementing (2^64-1) is 0.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com