mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: brauner@kernel.org, djwong@kernel.org, cem@kernel.org,
	dchinner@redhat.com, hch@lst.de
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com,
	ritesh.list@gmail.com, martin.petersen@oracle.com, tytso@mit.edu,
	linux-ext4@vger.kernel.org, John Garry <john.g.garry@oracle.com>
Subject: [PATCH v6 08/13] xfs: reflink CoW-based atomic write support
Date: Thu, 13 Mar 2025 17:13:05 +0000	[thread overview]
Message-ID: <20250313171310.1886394-9-john.g.garry@oracle.com> (raw)
In-Reply-To: <20250313171310.1886394-1-john.g.garry@oracle.com>

Add reflink support for CoW-based atomic writes.

A new flag - XFS_REFLINK_FORCE_COW - is added to indicate that a
COW fork extent mapping must be returned from xfs_reflink_allocate_cow().

For atomic writes, the idea is that first a CoW fork staging extent is
allocated and then the data is written to the new extent before finally
atomically the mapping is updated.

The semantics are that if XFS_REFLINK_FORCE_COW is set, we will be passed
a CoW fork extent mapping for no error returned.

If XFS_REFLINK_FORCE_COW is set and we find a real extent in the COW fork,
then continue to return that directly, as this would this belong to either
a. the same CoW fork extent which the atomic write previously allocated.
b. a pre-existing real cow extent which is unwritten

A atomic write cow fork extent should not be shared with other inodes,
and will only exist for the lifetime of the atomic write.

Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 fs/xfs/xfs_reflink.c | 18 ++++++++++++++++--
 fs/xfs/xfs_reflink.h |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index 674a812ecb4f..690b1eefeb0e 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -466,7 +466,7 @@ xfs_reflink_fill_cow_hole(
 	*lockmode = XFS_ILOCK_EXCL;
 
 	error = xfs_find_trim_cow_extent(ip, imap, cmap, shared, &found);
-	if (error || !*shared)
+	if (error || (!*shared && !(flags & XFS_REFLINK_FORCE_COW)))
 		goto out_trans_cancel;
 
 	if (found) {
@@ -582,9 +582,23 @@ xfs_reflink_allocate_cow(
 	}
 
 	error = xfs_find_trim_cow_extent(ip, imap, cmap, shared, &found);
-	if (error || !*shared)
+	if (error)
 		return error;
 
+	/*
+	 * For no shared data extent, return only as long as
+	 * XFS_REFLINK_FORCE_COW is not set.
+	 *
+	 * For XFS_REFLINK_FORCE_COW set, we always return a COW fork extent
+	 * mapping. That would be from either a previously allocated unwritten
+	 * COW fork extent, or else a new COW fork extent needs to be
+	 * allocated. A previously allocated unwritten COW fork extent could be
+	 * from an earlier call with XFS_REFLINK_FORCE_COW set or from a
+	 * earlier normal unshare of a data extent.
+	 */
+	if (!*shared && !(flags & XFS_REFLINK_FORCE_COW))
+		return 0;
+
 	/* CoW fork has a real extent */
 	if (found)
 		return xfs_reflink_convert_unwritten(ip, imap, cmap,
diff --git a/fs/xfs/xfs_reflink.h b/fs/xfs/xfs_reflink.h
index 18f9624017cd..f4115836064b 100644
--- a/fs/xfs/xfs_reflink.h
+++ b/fs/xfs/xfs_reflink.h
@@ -11,6 +11,8 @@
  */
 /* convert unwritten extents now */
 #define XFS_REFLINK_CONVERT_UNWRITTEN		(1u << 0)
+/* force a new COW mapping to be allocated */
+#define XFS_REFLINK_FORCE_COW			(1u << 1)
 
 /*
  * Check whether it is safe to free COW fork blocks from an inode. It is unsafe
-- 
2.31.1


  parent reply	other threads:[~2025-03-13 17:13 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 17:12 [PATCH v6 00/13] large atomic writes for xfs with CoW John Garry
2025-03-13 17:12 ` [PATCH v6 01/13] iomap: inline iomap_dio_bio_opflags() John Garry
2025-03-16 13:40   ` Ritesh Harjani
2025-03-17  6:07   ` Christoph Hellwig
2025-03-13 17:12 ` [PATCH v6 02/13] iomap: comment on atomic write checks in iomap_dio_bio_iter() John Garry
2025-03-17  6:08   ` Christoph Hellwig
2025-03-17  8:22     ` John Garry
2025-03-17 14:16   ` Ritesh Harjani
2025-03-13 17:13 ` [PATCH v6 03/13] iomap: rework IOMAP atomic flags John Garry
2025-03-17  6:11   ` Christoph Hellwig
2025-03-17  9:05     ` John Garry
2025-03-18  5:32       ` Christoph Hellwig
2025-03-18  8:11         ` John Garry
2025-03-17 13:44   ` Ritesh Harjani
2025-03-17 14:25     ` John Garry
2025-03-13 17:13 ` [PATCH v6 04/13] xfs: pass flags to xfs_reflink_allocate_cow() John Garry
2025-03-17  6:15   ` Christoph Hellwig
2025-03-17  9:17     ` John Garry
2025-03-18  5:33       ` Christoph Hellwig
2025-03-18  8:12         ` John Garry
2025-03-13 17:13 ` [PATCH v6 05/13] xfs: allow block allocator to take an alignment hint John Garry
2025-03-17  6:16   ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 06/13] xfs: switch atomic write size check in xfs_file_write_iter() John Garry
2025-03-17  6:18   ` Christoph Hellwig
2025-03-17  9:17     ` John Garry
2025-03-13 17:13 ` [PATCH v6 07/13] xfs: refactor xfs_reflink_end_cow_extent() John Garry
2025-03-17  6:19   ` Christoph Hellwig
2025-03-13 17:13 ` John Garry [this message]
2025-03-17  6:20   ` [PATCH v6 08/13] xfs: reflink CoW-based atomic write support Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 09/13] xfs: add XFS_REFLINK_ALLOC_EXTSZALIGN John Garry
2025-03-13 18:03   ` Darrick J. Wong
2025-03-17  6:23   ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 10/13] xfs: iomap COW-based atomic write support John Garry
2025-03-16  6:53   ` Ritesh Harjani
2025-03-17  8:54     ` John Garry
2025-03-17 14:20       ` Ritesh Harjani
2025-03-17 14:56         ` John Garry
2025-03-18  5:35           ` Christoph Hellwig
2025-03-17  7:26   ` Christoph Hellwig
2025-03-17 10:18     ` John Garry
2025-03-18  5:39       ` Christoph Hellwig
2025-03-18  8:22         ` John Garry
2025-03-18  8:32           ` Christoph Hellwig
2025-03-18 17:44             ` John Garry
2025-03-19  7:30               ` Christoph Hellwig
2025-03-19 10:24                 ` John Garry
2025-03-20  5:29                   ` Christoph Hellwig
2025-03-20  9:49                     ` John Garry
2025-03-20 14:12                       ` Christoph Hellwig
2025-03-13 17:13 ` [PATCH v6 11/13] xfs: add xfs_file_dio_write_atomic() John Garry
2025-03-17  6:41   ` Christoph Hellwig
2025-03-17  9:36     ` John Garry
2025-03-18  5:43       ` Christoph Hellwig
2025-03-18  8:42         ` John Garry
2025-03-18  8:46           ` Christoph Hellwig
2025-03-18  9:12             ` John Garry
2025-03-13 17:13 ` [PATCH v6 12/13] xfs: commit CoW-based atomic writes atomically John Garry
2025-03-17  6:56   ` Christoph Hellwig
2025-03-17  9:43     ` John Garry
2025-03-13 17:13 ` [PATCH v6 13/13] xfs: update atomic write max size John Garry
2025-03-17  7:25   ` Christoph Hellwig
2025-03-17  9:57     ` John Garry
2025-03-18  5:47       ` Christoph Hellwig
2025-03-18  5:48 ` [PATCH v6 00/13] large atomic writes for xfs with CoW Christoph Hellwig
2025-03-18  8:44   ` John Garry

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=20250313171310.1886394-9-john.g.garry@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®