[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221019111315.hpilifogyvf3bixh@wittgenstein>
Date: Wed, 19 Oct 2022 13:13:15 +0200
From: Christian Brauner <brauner@...nel.org>
To: Jeff Layton <jlayton@...nel.org>
Cc: tytso@....edu, adilger.kernel@...ger.ca, djwong@...nel.org,
david@...morbit.com, trondmy@...merspace.com, neilb@...e.de,
viro@...iv.linux.org.uk, zohar@...ux.ibm.com, xiubli@...hat.com,
chuck.lever@...cle.com, lczerner@...hat.com, jack@...e.cz,
bfields@...ldses.org, fweimer@...hat.com,
linux-btrfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, ceph-devel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-xfs@...r.kernel.org
Subject: Re: [PATCH v7 0/9] fs: clean up handling of i_version counter
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.
Powered by blists - more mailing lists