Analyses / Filesystem engineering

Fast file clones: where the copying cost goes

Published 15 October 2026 / Paper and API review

A fast logical copy tells you when a new view became available. It does not tell you how much work later changes will require, whether a whole application was captured consistently, or whether the copy survives loss of its storage.

Three operations that are not interchangeable

A hard link gives the same file another name: writes through either name affect the same contents. It is not a private working copy. [5] Linux FICLONE instead shares storage while preserving isolation of later writes; it requires the same filesystem and is atomic relative to concurrent writes. That is a per-operation contract, not a directory-tree transaction. [2]

copy_file_range() is a third interface. It permits in-kernel copying and filesystem acceleration, including reflinks or server-side copying. Its name does not identify which mechanism ran. A successful call can return fewer bytes than requested; callers must account for progress and stop appropriately at EOF. [3]

The engineering consequence is that equal file hashes establish equal observed bytes, not independent allocation or an independent failure domain. Record the operation and its outcome separately from the recovery claim.

Ordinary cp may already try a reflink

The GNU manual reviewed here documents --reflink=auto as the default. It falls back to ordinary copying when cloning is unsupported. --reflink=always requires cloning and reports failure when unavailable; --reflink=never disables this copy-on-write mode. Do not assume another utility or older installation has the same default. [4]

GNU also warns that an I/O error in shared data blocks affects both files. Choosing --reflink=never is a copying-policy choice, not proof of a different disk, pool, account or site. Those remain separate questions.

Capacity can be needed after cloning succeeds

Copy-on-write may need new storage on a later modification. Where supported, FALLOC_FL_UNSHARE_RANGE makes shared extents private so subsequent writes will not fail for lack of filesystem space. The operation itself must succeed. [6] This does not establish end-to-end capacity in an underlying thin-provisioned pool; see allocation at different layers.

For a fleet of writable clones, our recommendation is to budget for divergence as well as initial creation. Report retained versions, workload duration and available space. A test stopped immediately after creating its clones answers a much narrower question than a service that keeps changing them.

An obscure alternative: copy-on-abundant-write

Zhan and colleagues' FAST 2020 How to Copy Files studies a granularity trade-off: coarse copying can amplify small updates, while fine-grained copying can fragment later reads. BetrFS 0.5 buffers changes and delays unsharing until enough work accumulates, a policy called copy-on-abundant-write. Structural maintenance can also trigger unsharing. [1, sections 1-4]

Its Dookubench workload clones a 256 MiB directory, makes 16-byte edits per file, synchronizes, then measures cold-cache scans and space. The platform used a 7200 RPM SATA disk; BetrFS used a modified Linux 3.11.10, competitors 4.9.142. Unless stated otherwise, runs were repeated at least five times; plotted bounds are minima and maxima, not confidence intervals. [1, section 5]

These are historical prototype results, not measurements of modern XFS, Btrfs or NVMe. We have not reproduced them. The useful research question is whether cloning, modification and subsequent reads can all remain efficient.

Measure the lifecycle, not just creation

Hesela's proposed comparison worksheet. These are questions for a controlled experiment, not reported benchmark results.

Stage	Record	Question answered
Create	Requested API, fallback, elapsed time, file count.	Did the intended operation actually run?
Modify	Changed bytes and offsets, write latency, explicit persistence step.	What does making each clone different cost?
Read again	Same scan/query, cache state, latency distribution.	Did later access become more expensive?
Retain and reclaim	Shared/private allocation, free space, retained history, cleanup time.	When is space consumed and returned?

Choose the application-level comparison first: for example, a prepared test workspace becoming usable after its expected edits. Keep source contents, destination state, filesystem options, compression and persistence requirements fixed. Randomize run order, preserve individual observations and explain exclusions. Treat fallback copies as a separate group rather than averaging them into clone timings.

A syscall trace can help identify a requested mechanism, but tracing changes timing. Use a separate diagnostic run. Avoid machine-wide cache dropping on a shared or production host. Any cold-cache protocol belongs on an isolated test system with its effects documented.

File isolation is not a complete backup contract

A sequence of individually consistent file clones can combine different moments of a changing application. Our inference from the per-file contract: application coordination or an appropriate multi-object snapshot mechanism is still needed. Nor does logical isolation protect against loss of the shared filesystem.

Start with snapshot and backup failure boundaries and verify an actual restore. Definitions: reflink,copy_file_range and copy-on-write.

Primary sources and scope

Source review: 15 October 2026. API details follow Linux man-pages 6.19; actual support depends on kernel and filesystem. No new performance, failure-rate or recovery measurements are claimed.