[PATCH 0/2] btrfs: allow reflinks into NODATASUM files

[PATCH 0/2] btrfs: allow reflinks into NODATASUM files

[Daan De Meyer via B4 Relay]

The primary use case for this series is building a NOCOW VM image from
individual partition images that are COW and checksummed. Today those
partitions cannot be cloned into the NODATACOW and NODATASUM destination,
so tools fall back to a full copy. This makes provisioning slower and
duplicates all of the image data up front.

Allow cloning and deduplication from a checksummed file into a NODATASUM
file. The VM image can then share extents with the partition images.
Existing checksummed extents are COWed once when modified, protecting the
source checksums, while newly allocated extents use the destination's
normal NOCOW behavior.

The reverse direction remains rejected because the destination would
expect checksums that do not exist.

Patch 1 prevents swap activation from bypassing the COW protection when a
NODATASUM file references checksummed extents. Patch 2 relaxes the reflink
restriction in the safe direction.

The xfstests branch is available at:
https://github.com/kdave/xfstests/pull/6

Signed-off-by: Daan De Meyer <daan@amutable.com>
---
Daan De Meyer (2):
      btrfs: reject swapfile activation if any extent has checksums
      btrfs: allow reflinking from checksummed files into nodatasum files

 fs/btrfs/inode.c   | 29 +++++++++++++++++++++++++++++
 fs/btrfs/reflink.c | 18 ++++++++++++++----
 2 files changed, 43 insertions(+), 4 deletions(-)
---
base-commit: cab9e339cfbc1a4e075e53e281dfb00391e1a6bb
change-id: 20260712-reflink-into-nodatasum-aff962f3794e

Best regards,
--  
Daan De Meyer <daan@amutable.com>

[PATCH 1/2] btrfs: reject swapfile activation if any extent has checksums

[Daan De Meyer via B4 Relay]

From: Daan De Meyer <daan@amutable.com>

btrfs_swap_activate() checks that the file is NODATACOW and NODATASUM
and that none of its extents are shared, but it does not check that the
extents are actually free of checksum items.

Once an inode with NODATASUM set can reference extents that have
checksums in the csum tree, which a subsequent patch allows by
permitting reflinks from checksummed files into NODATASUM files, this
becomes a corruption vector:

  1. Reflink a checksummed file into a NODATASUM file.
  2. Delete the source file, so the extents are no longer shared.
  3. mkswap + swapon the NODATASUM file. The existing NODATACOW,
     NODATASUM and sharedness checks all pass.
  4. Writes to the active swap file go to disk directly, bypassing the
     COW fallback in can_nocow_file_extent() that everywhere else
     prevents in-place writes over extents that have checksums.

Such writes invalidate the checksums that remain in the csum tree,
after which scrub and read repair report, and on profiles with
redundancy attempt to repair, false corruption.

Close the hole by rejecting swap file activation if checksums exist for
any of the file's extents, mirroring the checksum lookup done by
can_nocow_file_extent().

Signed-off-by: Daan De Meyer <daan@amutable.com>
---
 fs/btrfs/inode.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 272598f6ae77..76a637f4263d 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -10216,6 +10216,7 @@ static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file,
 		struct extent_buffer *leaf;
 		struct btrfs_file_extent_item *ei;
 		struct btrfs_block_group *bg;
+		struct btrfs_root *csum_root;
 		u64 logical_block_start;
 		u64 physical_block_start;
 		u64 extent_gen;
@@ -10300,6 +10301,34 @@ static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file,
 			goto out;
 		}
 
+		/*
+		 * The extents may have csums despite the NODATASUM inode flag,
+		 * from a reflink of a checksummed file into this file. Writes
+		 * to an active swap file bypass the COW fallback that protects
+		 * such extents everywhere else (see can_nocow_file_extent()),
+		 * so they would invalidate the csums and make scrub and read
+		 * repair report false corruption.
+		 */
+		csum_root = btrfs_csum_root(fs_info, logical_block_start);
+		if (unlikely(!csum_root)) {
+			btrfs_err(fs_info,
+				  "missing csum root for extent at bytenr %llu",
+				  logical_block_start);
+			ret = -EUCLEAN;
+			goto out;
+		}
+		ret = btrfs_lookup_csums_list(csum_root, logical_block_start,
+					      logical_block_start + len - 1,
+					      NULL, false);
+		if (ret < 0)
+			goto out;
+		if (ret > 0) {
+			btrfs_warn(fs_info,
+				   "swapfile must not have checksummed extents");
+			ret = -EINVAL;
+			goto out;
+		}
+
 		map = btrfs_get_chunk_map(fs_info, logical_block_start, len);
 		if (IS_ERR(map)) {
 			ret = PTR_ERR(map);

-- 
2.54.0

[PATCH 2/2] btrfs: allow reflinking from checksummed files into nodatasum files

[Daan De Meyer via B4 Relay]

From: Daan De Meyer <daan@amutable.com>

Cloning and deduplication have always been rejected when the source and
destination inodes differ in their NODATASUM flag, making it impossible
to reflink data from a regular, checksummed file into a NODATACOW file.
This is a long-standing annoyance for use cases like copying VM images
into chattr +C directories, where cp --reflink=auto silently degrades
to a full data copy, as previously reported.

The restriction is only needed in one direction. Checksum items live in
the csum tree keyed by disk bytenr and are shared by every inode that
references an extent, and a clone operation copies no csum items at
all. Therefore:

- Reflinking from a NODATASUM file into a checksummed file would make
  the destination refer to extents that have no checksums, and reads of
  those extents would fail with -EIO. Creating the missing checksums at
  clone time is not an option either: besides making the clone read and
  checksum the full range, the checksums would be shared with the
  source file, whose NOCOW behavior would then silently break, as
  writes never go in place for extents that have checksums. This
  direction remains rejected.

- Reflinking from a checksummed file into a NODATASUM file is safe. The
  destination inode has NODATASUM set, so reads through it never verify
  checksums, and the on-disk state it creates, a NODATASUM inode
  referencing extents that have checksums, is already handled correctly
  everywhere:

  * can_nocow_file_extent() forces COW for any range that has
    checksums, so in-place writes can never invalidate the checksums
    shared with the source, even after the source file is deleted and
    the extents are no longer shared. The first write to a cloned range
    COWs into a fresh extent without checksums, after which NOCOW
    behavior resumes. This is the same "COW once" behavior that NOCOW
    files already have after a snapshot.

  * fsync of the destination logs no csum items, and log replay only
    deletes csums that were found in the log, so replaying the
    destination cannot remove the checksums of the source's extents.

  * Scrub, balance and device replace operate on the csum tree per
    extent and do not consult inode flags. Relocation already tolerates
    per-extent mixed checksum state via EXTENT_NODATASUM.

  * Swap file activation rejects files with checksummed extents as of
    the previous patch.

Relax the check in btrfs_remap_file_range_prep() to only reject the
NODATASUM source -> checksummed destination direction. This applies to
both clone and dedupe, which share the prep code.

Link: https://lore.kernel.org/all/CA+H1V9zNSiJgXj6w8i2syhm_4qeaxkYPZHuxLgjmfP-jjGMYBQ@mail.gmail.com/
Signed-off-by: Daan De Meyer <daan@amutable.com>
---
 fs/btrfs/reflink.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
index 9a49d2ecb949..9dab689ea388 100644
--- a/fs/btrfs/reflink.c
+++ b/fs/btrfs/reflink.c
@@ -858,11 +858,21 @@ static int btrfs_remap_file_range_prep(struct file *file_in, loff_t pos_in,
 	if (IS_ENCRYPTED(&inode_in->vfs_inode) != IS_ENCRYPTED(&inode_out->vfs_inode))
 		return -EINVAL;
 
-	/* Don't make the dst file partly checksummed */
-	if ((inode_in->flags & BTRFS_INODE_NODATASUM) !=
-	    (inode_out->flags & BTRFS_INODE_NODATASUM)) {
+	/*
+	 * Reflinking from a NODATASUM inode into a checksummed inode would
+	 * make the destination refer to extents that have no csum items in
+	 * the csum tree, and reads of those extents would then fail with
+	 * -EIO. We can't create the missing csums here, so reject it.
+	 *
+	 * The other direction is safe: the destination inode has NODATASUM
+	 * set, so reads through it never verify csums, and any write over a
+	 * range whose extent has csums is forced to COW into a new extent
+	 * (see can_nocow_file_extent()), so the csums shared with the source
+	 * extents can never be invalidated by in-place writes.
+	 */
+	if ((inode_in->flags & BTRFS_INODE_NODATASUM) &&
+	    !(inode_out->flags & BTRFS_INODE_NODATASUM))
 		return -EINVAL;
-	}
 
 	/*
 	 * Now that the inodes are locked, we need to start writeback ourselves

-- 
2.54.0

Re: [PATCH 0/2] btrfs: allow reflinks into NODATASUM files

[Neal Gompa]

On Sun, Jul 12, 2026 at 10:25 AM Daan De Meyer via B4 Relay
<devnull+daan.amutable.com@kernel.org> wrote:
>
> The primary use case for this series is building a NOCOW VM image from
> individual partition images that are COW and checksummed. Today those
> partitions cannot be cloned into the NODATACOW and NODATASUM destination,
> so tools fall back to a full copy. This makes provisioning slower and
> duplicates all of the image data up front.
>
> Allow cloning and deduplication from a checksummed file into a NODATASUM
> file. The VM image can then share extents with the partition images.
> Existing checksummed extents are COWed once when modified, protecting the
> source checksums, while newly allocated extents use the destination's
> normal NOCOW behavior.
>
> The reverse direction remains rejected because the destination would
> expect checksums that do not exist.
>
> Patch 1 prevents swap activation from bypassing the COW protection when a
> NODATASUM file references checksummed extents. Patch 2 relaxes the reflink
> restriction in the safe direction.
>
> The xfstests branch is available at:
> https://github.com/kdave/xfstests/pull/6
>
> Signed-off-by: Daan De Meyer <daan@amutable.com>
> ---
> Daan De Meyer (2):
>       btrfs: reject swapfile activation if any extent has checksums
>       btrfs: allow reflinking from checksummed files into nodatasum files
>
>  fs/btrfs/inode.c   | 29 +++++++++++++++++++++++++++++
>  fs/btrfs/reflink.c | 18 ++++++++++++++----
>  2 files changed, 43 insertions(+), 4 deletions(-)
> ---
> base-commit: cab9e339cfbc1a4e075e53e281dfb00391e1a6bb
> change-id: 20260712-reflink-into-nodatasum-aff962f3794e
>

The patch series looks good to me.

Reviewed-by: Neal Gompa <neal@gompa.dev>

That said, I have a question: Is there no reason we couldn't reflink
into a checksummed area and generate *new* checksums for that purpose?
That would be useful for staging for regular backup.

I can foresee that being useful for archiving OS trees or VM images as
snapshots by creating checksums for the newly created snapshots...



--
真実はいつも一つ！/ Always, there's only one truth!

Re: [PATCH 0/2] btrfs: allow reflinks into NODATASUM files

[Qu Wenruo]

在 2026/7/12 23:55, Daan De Meyer via B4 Relay 写道:
> The primary use case for this series is building a NOCOW VM image from
> individual partition images that are COW and checksummed. Today those
> partitions cannot be cloned into the NODATACOW and NODATASUM destination,
> so tools fall back to a full copy. This makes provisioning slower and
> duplicates all of the image data up front.
> 
> Allow cloning and deduplication from a checksummed file into a NODATASUM
> file. The VM image can then share extents with the partition images.
> Existing checksummed extents are COWed once when modified, protecting the
> source checksums, while newly allocated extents use the destination's
> normal NOCOW behavior.

No, the change will easily cause btrfs check errors, in both lowmem and 
original modes.

And before you do anything weird, I'd prefer you to address the 
regression caused by your new 32bit compatible ioctl first:

https://lore.kernel.org/linux-btrfs/66470c2e-56b9-49a9-9cd2-aa49fac75bbf@suse.com/
> 
> The reverse direction remains rejected because the destination would
> expect checksums that do not exist.
> 
> Patch 1 prevents swap activation from bypassing the COW protection when a
> NODATASUM file references checksummed extents. Patch 2 relaxes the reflink
> restriction in the safe direction.
> 
> The xfstests branch is available at:
> https://github.com/kdave/xfstests/pull/6
> 
> Signed-off-by: Daan De Meyer <daan@amutable.com>
> ---
> Daan De Meyer (2):
>        btrfs: reject swapfile activation if any extent has checksums
>        btrfs: allow reflinking from checksummed files into nodatasum files
> 
>   fs/btrfs/inode.c   | 29 +++++++++++++++++++++++++++++
>   fs/btrfs/reflink.c | 18 ++++++++++++++----
>   2 files changed, 43 insertions(+), 4 deletions(-)
> ---
> base-commit: cab9e339cfbc1a4e075e53e281dfb00391e1a6bb
> change-id: 20260712-reflink-into-nodatasum-aff962f3794e
> 
> Best regards,
> --
> Daan De Meyer <daan@amutable.com>
> 
> 
> 

Re: [PATCH 0/2] btrfs: allow reflinks into NODATASUM files

[Qu Wenruo]

在 2026/7/13 00:36, Neal Gompa 写道:
> On Sun, Jul 12, 2026 at 10:25 AM Daan De Meyer via B4 Relay
> <devnull+daan.amutable.com@kernel.org> wrote:
>>
>> The primary use case for this series is building a NOCOW VM image from
>> individual partition images that are COW and checksummed. Today those
>> partitions cannot be cloned into the NODATACOW and NODATASUM destination,
>> so tools fall back to a full copy. This makes provisioning slower and
>> duplicates all of the image data up front.
>>
>> Allow cloning and deduplication from a checksummed file into a NODATASUM
>> file. The VM image can then share extents with the partition images.
>> Existing checksummed extents are COWed once when modified, protecting the
>> source checksums, while newly allocated extents use the destination's
>> normal NOCOW behavior.
>>
>> The reverse direction remains rejected because the destination would
>> expect checksums that do not exist.
>>
>> Patch 1 prevents swap activation from bypassing the COW protection when a
>> NODATASUM file references checksummed extents. Patch 2 relaxes the reflink
>> restriction in the safe direction.
>>
>> The xfstests branch is available at:
>> https://github.com/kdave/xfstests/pull/6
>>
>> Signed-off-by: Daan De Meyer <daan@amutable.com>
>> ---
>> Daan De Meyer (2):
>>        btrfs: reject swapfile activation if any extent has checksums
>>        btrfs: allow reflinking from checksummed files into nodatasum files
>>
>>   fs/btrfs/inode.c   | 29 +++++++++++++++++++++++++++++
>>   fs/btrfs/reflink.c | 18 ++++++++++++++----
>>   2 files changed, 43 insertions(+), 4 deletions(-)
>> ---
>> base-commit: cab9e339cfbc1a4e075e53e281dfb00391e1a6bb
>> change-id: 20260712-reflink-into-nodatasum-aff962f3794e
>>
> 
> The patch series looks good to me.
> 
> Reviewed-by: Neal Gompa <neal@gompa.dev>

I appreciate your feedback as an end user/sys admin, but I doubt if you 
really understand the requirement or tried the patch by yourself.

I'd appreciate if you put more weight behind your reviewed-by tags.

> 
> That said, I have a question: Is there no reason we couldn't reflink
> into a checksummed area and generate *new* checksums for that purpose?
> That would be useful for staging for regular backup.

Because btrfs' NODATASUM/NODATACOW flag is per-inode, as that's the only 
way we can store that flag.

If you really want proper per-extent NODATASUM/NODATACOW, there will 
need a huge change in the on-disk format, e.g. introducing new flags 
into btrfs_file_extent_item, and do the extra work handling corner cases 
like preallocation.

It's definitely not as simple two small patches.

> 
> I can foresee that being useful for archiving OS trees or VM images as
> snapshots by creating checksums for the newly created snapshots...

Nope, one should not combine VM images with snapshots on btrfs.

Even if we have fixed all the direct IO problems, the extent bookend 
will waste a lot of space.

> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> 

Re: [PATCH 0/2] btrfs: allow reflinks into NODATASUM files

[Neal Gompa]

On Sun, Jul 12, 2026 at 6:19 PM Qu Wenruo <wqu@suse.com> wrote:
>
>
>
> 在 2026/7/13 00:36, Neal Gompa 写道:
> > On Sun, Jul 12, 2026 at 10:25 AM Daan De Meyer via B4 Relay
> > <devnull+daan.amutable.com@kernel.org> wrote:
> >>
> >> The primary use case for this series is building a NOCOW VM image from
> >> individual partition images that are COW and checksummed. Today those
> >> partitions cannot be cloned into the NODATACOW and NODATASUM destination,
> >> so tools fall back to a full copy. This makes provisioning slower and
> >> duplicates all of the image data up front.
> >>
> >> Allow cloning and deduplication from a checksummed file into a NODATASUM
> >> file. The VM image can then share extents with the partition images.
> >> Existing checksummed extents are COWed once when modified, protecting the
> >> source checksums, while newly allocated extents use the destination's
> >> normal NOCOW behavior.
> >>
> >> The reverse direction remains rejected because the destination would
> >> expect checksums that do not exist.
> >>
> >> Patch 1 prevents swap activation from bypassing the COW protection when a
> >> NODATASUM file references checksummed extents. Patch 2 relaxes the reflink
> >> restriction in the safe direction.
> >>
> >> The xfstests branch is available at:
> >> https://github.com/kdave/xfstests/pull/6
> >>
> >> Signed-off-by: Daan De Meyer <daan@amutable.com>
> >> ---
> >> Daan De Meyer (2):
> >>        btrfs: reject swapfile activation if any extent has checksums
> >>        btrfs: allow reflinking from checksummed files into nodatasum files
> >>
> >>   fs/btrfs/inode.c   | 29 +++++++++++++++++++++++++++++
> >>   fs/btrfs/reflink.c | 18 ++++++++++++++----
> >>   2 files changed, 43 insertions(+), 4 deletions(-)
> >> ---
> >> base-commit: cab9e339cfbc1a4e075e53e281dfb00391e1a6bb
> >> change-id: 20260712-reflink-into-nodatasum-aff962f3794e
> >>
> >
> > The patch series looks good to me.
> >
> > Reviewed-by: Neal Gompa <neal@gompa.dev>
>
> I appreciate your feedback as an end user/sys admin, but I doubt if you
> really understand the requirement or tried the patch by yourself.
>
> I'd appreciate if you put more weight behind your reviewed-by tags.
>

I already don't review patches very often because of responses like
this. Please don't make me feel like I should pull out entirely.

> >
> > That said, I have a question: Is there no reason we couldn't reflink
> > into a checksummed area and generate *new* checksums for that purpose?
> > That would be useful for staging for regular backup.
>
> Because btrfs' NODATASUM/NODATACOW flag is per-inode, as that's the only
> way we can store that flag.
>
> If you really want proper per-extent NODATASUM/NODATACOW, there will
> need a huge change in the on-disk format, e.g. introducing new flags
> into btrfs_file_extent_item, and do the extra work handling corner cases
> like preallocation.
>
> It's definitely not as simple two small patches.
>

I wasn't implying that it was simple. I asked the question because the
patches themselves don't explain why it's not done, only that it's
"not safe". That is not a sufficient enough answer in my book. And
while I can intuit the reason from my own experience working on CoW
stuff before, I wanted to know why it was dismissed as "unsafe" when I
am aware of ways for it to be done.

> >
> > I can foresee that being useful for archiving OS trees or VM images as
> > snapshots by creating checksums for the newly created snapshots...
>
> Nope, one should not combine VM images with snapshots on btrfs.
>
> Even if we have fixed all the direct IO problems, the extent bookend
> will waste a lot of space.
>

In the real world, this combination happens *a lot*. In fact, multiple
businesses are built on this idea (though not using Btrfs
specifically). It is not out of the realm of possibility to me that
Btrfs would support it and that the weaknesses could be minimized.
Throwing the idea completely out is beyond silly because of how common
containers and virtual machines are. Both are used more and more, even
without people knowing it, so the idea that we shouldn't at least look
at making that pattern workable seems foolhardy.


-- 
真実はいつも一つ！/ Always, there's only one truth!