Re: [PATCH v7 0/9] fs: clean up handling of i_version counter

From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, djwong@kernel.org,
	david@fromorbit.com, trondmy@hammerspace.com, neilb@suse.de,
	viro@zeniv.linux.org.uk, zohar@linux.ibm.com, xiubli@redhat.com,
	chuck.lever@oracle.com, lczerner@redhat.com, jack@suse.cz,
	bfields@fieldses.org, fweimer@redhat.com,
	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: [PATCH v7 0/9] fs: clean up handling of i_version counter
Date: Wed, 19 Oct 2022 08:18:15 -0400	[thread overview]
Message-ID: <2b167dd9bda17f1324e9c526d868cc0d995dc660.camel@kernel.org> (raw)
In-Reply-To: <20221019111315.hpilifogyvf3bixh@wittgenstein>

On Wed, 2022-10-19 at 13:13 +0200, Christian Brauner wrote:
> On Mon, Oct 17, 2022 at 06:57:00AM -0400, Jeff Layton wrote:
> > This patchset is intended to clean up the handling of the i_version
> > counter by nfsd. Most of the changes are to internal interfaces.
> > 
> > This set is not intended to address crash resilience, or the fact that
> > the counter is bumped before a change and not after. I intend to tackle
> > those in follow-on patchsets.
> > 
> > My intention is to get this series included into linux-next soon, with
> > an eye toward merging most of it during the v6.2 merge window. The last
> > patch in the series is probably not suitable for merge as-is, at least
> > until we sort out the semantics we want to present to userland for it.
> 
> Over the course of the series I struggled a bit - and sorry for losing
> focus - with what i_version is supposed to represent for userspace. So I
> would support not exposing it to userspace before that. But that
> shouldn't affect your other changes iiuc.

Thanks Christian,

It has been a real struggle to nail this down, and yeah I too am not
planning to expose this to userland until we have this much better
defined. Patch #9 is just to give you an idea of what this would
ultimately look like. I intend to re-post the first 8 patches with an
eye toward merge in v6.2, once we've settled on the naming. On that
note...

I believe you had mentioned that you didn't like STATX_CHANGE_ATTR for
the name, and suggested STATX_I_VERSION (or something similar), which I
later shortened to STATX_VERSION.

Dave C. objected to STATX_VERSION, as "version" fields in a struct
usually refer to the version of the struct itself rather than the
version of the thing it describes. It also sort of implies a monotonic
counter, and I'm not ready to require that just yet.

What about STATX_CHANGE for the name (with corresponding names for the
field and other flags)? That drops the redundant "_ATTR" postfix, while
being sufficiently vague to allow for alternative implementations in the
future.

Do you (or anyone else) have other suggestions for a name?
-- 
Jeff Layton <jlayton@kernel.org>