From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH 02/14] xfs: introduce new file range exchange ioctls
Date: Wed, 28 Feb 2024 07:44:32 -0800 [thread overview]
Message-ID: <Zd9U4GAYxqw7zpXe@infradead.org> (raw)
In-Reply-To: <170900011673.938268.12940080187778287002.stgit@frogsfrogsfrogs>
On Mon, Feb 26, 2024 at 06:21:23PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> Introduce a pair of new ioctls to handle exchanging ranges of bytes
> between files. The goal here is to perform the exchange atomically with
> respect to applications -- either they see the file contents before the
> exchange or they see that A-B is now B-A, even if the kernel crashes.
>
> The simpler of the two ioctls is XFS_IOC_EXCHANGE_RANGE, which performs
> the exchange unconditionally. XFS_IOC_COMMIT_RANGE, on the other hand,
> requires the caller to sample the file attributes of one of the files
> participating in the exchange, and aborts the exchange if that file has
> changed in the meantime (presumably by another thread).
So per all the discussions, wouldn't it make sense to separate out
XFS_IOC_COMMIT_RANGE (plus the new start commit one later), and if
discussions are still going on just get XFS_IOC_EXCHANGE_RANGE
done ASAP to go on with online repair, and give XFS_IOC_COMMIT_RANGE
enough time to discuss the finer details?
> +struct xfs_exch_range {
> + __s64 file1_fd;
I should have noticed this last time, by why are we passing a fd
as a 64-bit value when it actually just is a 32-bit value in syscalls?
(same for commit).
> + if (((fxr->file1->f_flags | fxr->file2->f_flags) & (__O_SYNC | O_DSYNC)) ||
Nit: overly long line here.
> + if (fxr->flags & ~(XFS_EXCHRANGE_ALL_FLAGS | __XFS_EXCHRANGE_CHECK_FRESH2))
.. and here
> + /*
> + * The ioctl enforces that src and dest files are on the same mount.
> + * However, they only need to be on the same file system.
> + */
> + if (inode1->i_sb != inode2->i_sb)
> + return -EXDEV;
How about only doing this checks once further up? As the same sb also
applies the same mount.
next prev parent reply other threads:[~2024-02-28 15:44 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 [this message]
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
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=Zd9U4GAYxqw7zpXe@infradead.org \
--to=hch@infradead.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--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