Re: [PATCH 0/2] btrfs: allow reflinks into NODATASUM files
Neal Gompa <[email protected]>
| Newsgroups | org.kernel.vger.linux-btrfs,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAEg-Je86cbtNvESfK5MeVXVezZfMFE8qVdX900F3ayQsC+yQNg@mail.gmail.com> |
On Sun, Jul 12, 2026 at 10:25 AM Daan De Meyer via B4 Relay <[email protected]> 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 <[email protected]> > --- > 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 <[email protected]> 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!