lkml.org 
[lkml]   [2022]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 0/9] fs: clean up handling of i_version counter
On Wed, Oct 19, 2022 at 08:18:15AM -0400, Jeff Layton wrote:
> 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?

Welllll it's really a u32 whose value doesn't have any intrinsic meaning
other than "if (value_now != value_before) flush_cache();" right?
I think it really only tracks changes to file data, right?

STATX_CHANGE_COOKIE (wait, does this cookie augment i_ctime?)

STATX_MOD_COOKIE (...or just file modifications/i_mtime?)

STATX_MONITOR_COOKIE (...what are we monitoring??)

STATX_MON_COOKIE

STATX_COOKIE_MON

STATX_COOKIE_MONSTER

There we go. ;)

In seriousness, I'd probably go with one of the first two. I wouldn't
be opposed to the last one, either, but others may disagree. ;)

--D

> --
> Jeff Layton <jlayton@kernel.org>

\
 
 \ /
  Last update: 2022-10-19 17:52    [W:0.062 / U:0.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site