public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	hch@lst.de
Subject: Re: [PATCHSET v29.4 03/13] xfs: atomic file content exchanges
Date: Wed, 28 Feb 2024 10:46:07 +1100	[thread overview]
Message-ID: <Zd50P9TH5TAdqFyU@dread.disaster.area> (raw)
In-Reply-To: <4e29a0395b3963e6a48f916baaf16394acd017ca.camel@kernel.org>

On Tue, Feb 27, 2024 at 05:53:46AM -0500, Jeff Layton wrote:
> On Tue, 2024-02-27 at 11:23 +0200, Amir Goldstein wrote:
> > On Tue, Feb 27, 2024 at 4:18 AM Darrick J. Wong <djwong@kernel.org> wrote:
> > And for a new API, wouldn't it be better to use change_cookie (a.k.a i_version)?

Like xfs_fsr doing online defrag, we really only care about explicit
user data changes here, not internal layout and metadata changes to
the files...

> > Even if this API is designed to be hoisted out of XFS at some future time,
> > Is there a real need to support it on filesystems that do not support
> > i_version(?)
> > 
> > Not to mention the fact that POSIX does not explicitly define how ctime should
> > behave with changes to fiemap (uninitialized extent and all), so who knows
> > how other filesystems may update ctime in those cases.
> > 
> > I realize that STATX_CHANGE_COOKIE is currently kernel internal, but
> > it seems that XFS_IOC_EXCHANGE_RANGE is a case where userspace
> > really explicitly requests a bump of i_version on the next change.
> > 
> 
> 
> I agree. Using an opaque change cookie would be a lot nicer from an API
> standpoint, and shouldn't be subject to timestamp granularity issues.
> 
> That said, XFS's change cookie is currently broken. Dave C. said he had
> some patches in progress to fix that however.

By "fix", I meant "remove".

i.e. the patches I was proposing were to remove SB_I_VERSION support
from XFS so NFS just uses the ctime on XFS because the recent
changes to i_version make it a ctime change counter, not an inode
change counter.

Then patches were posted for finer grained inode timestamps to allow
everything to use ctime instead of i_version, and with that I
thought NFS was just going to change to ctime for everyone with that
the whole change cookie issue was going away.

It now sounds like that isn't happening, so I'll just ressurect the
patch to remove published SB_I_VERSION and STATX_CHANGE_COOKIE
support from XFS for now and us XFS people can just go back to
ignoring this problem again.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2024-02-27 23:46 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27  2:18 [PATCHSET v29.4 03/13] xfs: atomic file content exchanges Darrick J. Wong
2024-02-27  2:21 ` [PATCH 01/14] vfs: export remap and write check helpers Darrick J. Wong
2024-02-28 15:40   ` Christoph Hellwig
2024-02-27  2:21 ` [PATCH 02/14] xfs: introduce new file range exchange ioctls Darrick J. Wong
2024-02-28 15:44   ` Christoph Hellwig
2024-02-28 19:35     ` Darrick J. Wong
2024-02-28 19:37       ` Christoph Hellwig
2024-02-28 23:00         ` Darrick J. Wong
2024-02-29 13:22           ` Christoph Hellwig
2024-02-29 17:10             ` Darrick J. Wong
2024-02-29 19:42               ` Christoph Hellwig
2024-02-27  2:21 ` [PATCH 03/14] xfs: create a log incompat flag for atomic file mapping exchanges Darrick J. Wong
2024-02-28 15:44   ` Christoph Hellwig
2024-02-27  2:21 ` [PATCH 04/14] xfs: introduce a file mapping exchange log intent item Darrick J. Wong
2024-02-28 15:45   ` Christoph Hellwig
2024-02-27  2:22 ` [PATCH 05/14] xfs: create deferred log items for file mapping exchanges Darrick J. Wong
2024-02-28 15:49   ` Christoph Hellwig
2024-02-28 19:55     ` Darrick J. Wong
2024-02-28 22:08       ` Christoph Hellwig
2024-02-28 22:56         ` Darrick J. Wong
2024-02-27  2:22 ` [PATCH 06/14] xfs: bind together the front and back ends of the file range exchange code Darrick J. Wong
2024-02-28 15:49   ` Christoph Hellwig
2024-02-27  2:22 ` [PATCH 07/14] xfs: add error injection to test file mapping exchange recovery Darrick J. Wong
2024-02-28 15:50   ` Christoph Hellwig
2024-02-27  2:22 ` [PATCH 08/14] xfs: condense extended attributes after a mapping exchange operation Darrick J. Wong
2024-02-28 15:50   ` Christoph Hellwig
2024-02-27  2:23 ` [PATCH 09/14] xfs: condense directories " Darrick J. Wong
2024-02-28 15:51   ` Christoph Hellwig
2024-02-27  2:23 ` [PATCH 10/14] xfs: condense symbolic links " Darrick J. Wong
2024-02-28 15:51   ` Christoph Hellwig
2024-02-27  2:23 ` [PATCH 11/14] xfs: make file range exchange support realtime files Darrick J. Wong
2024-02-28 15:51   ` Christoph Hellwig
2024-02-27  2:23 ` [PATCH 12/14] xfs: support non-power-of-two rtextsize with exchange-range Darrick J. Wong
2024-02-28 15:51   ` Christoph Hellwig
2024-02-27  2:24 ` [PATCH 13/14] docs: update swapext -> exchmaps language Darrick J. Wong
2024-02-28 15:52   ` Christoph Hellwig
2024-02-27  2:24 ` [PATCH 14/14] xfs: enable logged file mapping exchange feature Darrick J. Wong
2024-02-28 15:52   ` Christoph Hellwig
2024-02-27  9:23 ` [PATCHSET v29.4 03/13] xfs: atomic file content exchanges Amir Goldstein
2024-02-27 10:53   ` Jeff Layton
2024-02-27 16:06     ` Darrick J. Wong
2024-03-01 13:16       ` Jeff Layton
2024-02-27 23:46     ` Dave Chinner [this message]
2024-02-28 10:30       ` Jeff Layton
2024-02-28 10:58         ` Amir Goldstein
2024-02-28 11:01           ` Jeff Layton
2024-02-27 15:45   ` Darrick J. Wong
2024-02-27 16:58     ` Amir Goldstein
2024-02-27 17:46 ` [PATCH 14/13] xfs: make XFS_IOC_COMMIT_RANGE freshness data opaque Darrick J. Wong
2024-02-27 18:52   ` Amir Goldstein
2024-02-29 23:27     ` Darrick J. Wong
2024-03-01 13:00       ` Amir Goldstein
2024-03-01 13:31       ` Jeff Layton
2024-03-02  2:48         ` Darrick J. Wong
2024-03-02 12:43           ` Jeff Layton
2024-03-07 23:25             ` Darrick J. Wong
2024-02-28  1:50 ` [PATCHSET v29.4 03/13] xfs: atomic file content exchanges Colin Walters
2024-02-29 20:18   ` Darrick J. Wong
2024-02-29 22:43     ` Colin Walters
2024-03-01  0:03       ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zd50P9TH5TAdqFyU@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=amir73il@gmail.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox