Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25371.41798.87576.861659@quad.stoffel.home>
Date:   Fri, 9 Sep 2022 16:34:14 -0400
From:   "John Stoffel" <john@stoffel.org>
To:     Jeff Layton <jlayton@kernel.org>
Cc:     "J. Bruce Fields" <bfields@fieldses.org>,
        Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
        NeilBrown <neilb@suse.de>, adilger.kernel@dilger.ca,
        djwong@kernel.org, david@fromorbit.com, trondmy@hammerspace.com,
        viro@zeniv.linux.org.uk, zohar@linux.ibm.com, xiubli@redhat.com,
        chuck.lever@oracle.com, lczerner@redhat.com, brauner@kernel.org,
        fweimer@redhat.com, linux-man@vger.kernel.org,
        linux-api@vger.kernel.org, linux-btrfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new
 STATX_INO_VERSION field
In-Reply-To: <44efe219dbf511492b21a653905448d43d0f3363.camel@kernel.org>
References: <79aaf122743a295ddab9525d9847ac767a3942aa.camel@kernel.org>
        <20220907125211.GB17729@fieldses.org>
        <771650a814ab1ff4dc5473d679936b747d9b6cf5.camel@kernel.org>
        <20220907135153.qvgibskeuz427abw@quack3>
        <166259786233.30452.5417306132987966849@noble.neil.brown.name>
        <20220908083326.3xsanzk7hy3ff4qs@quack3>
        <YxoIjV50xXKiLdL9@mit.edu>
        <02928a8c5718590bea5739b13d6b6ebe66cac577.camel@kernel.org>
        <20220908155605.GD8951@fieldses.org>
        <9e06c506fd6b3e3118da0ec24276e85ea3ee45a1.camel@kernel.org>
        <20220908182252.GA18939@fieldses.org>
        <44efe219dbf511492b21a653905448d43d0f3363.camel@kernel.org>
Precedence: bulk

>>>>> "Jeff" == Jeff Layton <jlayton@kernel.org> writes:

> On Thu, 2022-09-08 at 14:22 -0400, J. Bruce Fields wrote:
>> On Thu, Sep 08, 2022 at 01:40:11PM -0400, Jeff Layton wrote:
>> > Yeah, ok. That does make some sense. So we would mix this into the
>> > i_version instead of the ctime when it was available. Preferably, we'd
>> > mix that in when we store the i_version rather than adding it afterward.
>> > 
>> > Ted, how would we access this? Maybe we could just add a new (generic)
>> > super_block field for this that ext4 (and other filesystems) could
>> > populate at mount time?
>> 
>> Couldn't the filesystem just return an ino_version that already includes
>> it?
>> 

> Yes. That's simple if we want to just fold it in during getattr. If we
> want to fold that into the values stored on disk, then I'm a little less
> clear on how that will work.

I wonder if this series should also include some updates to the
various xfstests to hopefully document in code what this statx() call
will do in various situations.  Or at least document how to test it in
some manner?  Especially since it's layers on top of layers to make
this work. 

My assumption is that if the underlying filesystem doesn't support the
new values, it just returns 0 or c_time?

John