[CMGS]

CloneFile's no-reflink fallback (copyData) is the dir checkpoint store's only copy path, and an archived-claim reader uses it.

Problems

• FUSE checkpoint_dir. JuiceFS has no SEEK_DATA/SEEK_HOLE, so the kernel reports the whole file as data. copyData then writes every zero byte. On hardware, a reader of an archived claim wrote its full 10 GiB cow.raw and was ready in 13.6 s, against 0.58 s and 522 MiB from ext4. docs/deploy.md recommends exactly this setup for checkpoint_dir.
• No-reflink filesystems (ext4). io.Copy through an OffsetWriter moves 32 KiB per syscall, about 32k reads and 32k writes per GiB.

Change

• Each data range is copied in 1 MiB blocks with ReadAt/WriteAt.
• An all-zero block is not written, so the destination, which is truncated to the source size first, keeps a hole there.
• IsZero moves from store/sparse.go to utils, and store.ScanFile uses the shared helper.
• docs/deploy.md: the reader section says the dir backend keeps zero blocks as holes even from a mount that reports none.
• TestCopyDataKeepsHoles covers two sources: a sparse file, and a file with 8 MiB of zeros written as data. The second case fails against the old copyData: it allocates 8392704 of 8388612 bytes.

Hardware

Pending. I'll run an A/B on ext4, with three arms: the old code, copy_file_range, and this change. On JuiceFS I'll compare the old code with this change. Both runs measure copy time and the destination's allocated bytes, and the results will be posted here.

Gates

• make go-lint: 10× 0 issues.
• asl -forwarder=false ./...: clean on both GOOS.
• go test -race ./utils/ ./store/... ./pool/: ok.
• Linux (golang:1.27.1 arm64, tmpfs): go test ./utils/ ./store/... ok.

[CMGS]

Hardware verification: pass

Setup. Testbed host, kernel 6.12, an otherwise idle NUMA node.

• sandboxd A = 707ef2c, C = a3ede46; both built clean.
• The bench has three arms:
  • A: origin/main copyData, verbatim.
  • B: Seek + io.CopyN, which uses copy_file_range.
  • C: this PR's utils.CloneFile.
• The source page cache is dropped every round.

ext4 without reflink (loop ext4). n=6 per arm, F1 run ABCCBA ×3 and F2 in the swapped order. Medians in ms, Mann-Whitney p in parentheses:

File	A	B	C	C vs A	C vs B
F1 4 GiB, 1 GiB data in 64 extents	914.6	830.8	877.6	−4.0% (0.004)	+5.6% (0.004)
F1 with fsync	1508.7	1429.4	1500.7	−0.5% (0.20)	+5.0% (0.016)
F2 2 GiB dense	1755.3	1589.3	1650.9	−6.0% (0.004)	+3.9% (0.004)
F2 with fsync	3008.6	2851.6	2874.6	−4.5% (0.007)	+0.8% (0.42)

• Syscalls per round for F1:
  • A: 32771 reads / 32768 writes.
  • B: about 70.
  • C: 1027 / 1024.
• Every arm's destination matched its source in allocated bytes, extent count and sha256.

JuiceFS dir store, first read of an archived claim. Run order A C C A A C, one fresh sandboxd per run.

	ready (median)	readers/ peak
A	12.58 s (11.5–14.0)	10240 MiB
C	5.69 s (5.66–5.72)	540 MiB

• On JuiceFS, the source cow.raw reports one 10 GiB data extent (fstype FUSE).
• Cloning it directly to xfs:
  • A: 6.12 s, 10 GiB allocated, 1 extent.
  • C: 5.17 s, 540 MiB allocated, 20 extents, sha256 equal to the source.

Tests on the Linux host.

• utils, store, store/dir, store/peer and store/s3 pass with TMPDIR on ext4.
• With TMPDIR on xfs, TestCloneFileRemovesFailedDestination fails. It fails identically on origin/main: xfs accepts FICLONE from a directory fd. No caller passes a directory, so this PR leaves the test alone.