| Message ID | 20221017105709.10830-1-jlayton@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | fs: clean up handling of i_version counter | expand |
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.
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?
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>
On Wed, 2022-10-19 at 08:45 -0700, Darrick J. Wong wrote: > 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? > It's a u64, but yeah, you're not supposed to assign any intrinsic meaning to the value itself. > 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 > > STATX_CHANGE_COOKIE is probably the best one. I'll plan to go with that unless someone has a better idea. Thanks for the suggestions! Cheers,
On Wed, Oct 19, 2022 at 04:36:47PM -0400, Jeff Layton wrote: > On Wed, 2022-10-19 at 08:45 -0700, Darrick J. Wong wrote: > > 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? > > > > It's a u64, but yeah, you're not supposed to assign any intrinsic > meaning to the value itself. > > > 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 > > > > > > STATX_CHANGE_COOKIE is probably the best one. I'll plan to go with that > unless someone has a better idea. Thanks for the suggestions! Sounds fine to me.