Great question—efficient file copying on COW-aware Linux filesystems is all about leveraging the right kernel interfaces at the right time, so let's break this down step by step.

The optimal approach follows a hierarchy:

1. Prioritize COW clones: These are instant and zero-overhead, since they just create shared blocks instead of copying data. Only works if the source and destination are on the same COW filesystem (Btrfs, XFS, ZFS, etc.).
2. Fall back to Server-Side Copy: If cross-filesystem or remote copies are needed (e.g., NFS 4.2, Ceph), use interfaces that trigger server-side data movement to avoid bouncing data through user space.
3. Use Zero-Copy as a last resort: For filesystems that don't support COW or server-side copy, use zero-copy mechanisms to keep data in the kernel (no user-space buffer copies).

Let's unpack each interface's capabilities, differences, and ideal use cases:

Feature Support Matrix #

FICLONE #

• COW Focus: Explicitly built for full-file COW clones on the same filesystem. When supported, it creates a reflink—new file shares all blocks with the source, no data copied.
• Limitations: Only works on the same filesystem; no cross-FS or remote support.
• Best For: Full-file copies where you know source/dest are on the same COW filesystem. It's simple, explicit, and has been around longer for legacy kernel support.

FICLONERANGE #

• COW Focus: Extended version of FICLONE that lets you clone specific ranges of a file (not the entire thing) to another file. Same COW requirements as FICLONE.
• Limitations: Same filesystem only, no server-side copy.
• Best For: Partial file clones (e.g., copying a segment of a large VM image or log file) on the same COW filesystem.

copy_file_range #

• Flexibility: The most versatile option here. Supports:
  • COW clones via the COPY_FILE_RANGE_COW flag (same filesystem).
  • Server-side copy for cross-filesystem or remote copies (e.g., NFS 4.2, where the server handles data movement directly).
  • Zero-copy in all modes—even when not using COW, data stays in kernel buffers instead of bouncing through user space.
• Best For:
  • Cross-filesystem or remote copies where server-side copy is available.
  • Partial file copies that need to work across different filesystem types.
  • Cases where you want a single interface to handle both COW and non-COW scenarios.

Do They Behave Identically When the FS Supports COW? #

Yes—when the underlying filesystem supports reflinks and you're working on the same filesystem:

• FICLONE is equivalent to calling FICLONERANGE with the entire file range, or calling copy_file_range with the full range and COPY_FILE_RANGE_COW flag. All three will create shared COW blocks with no data copied.
• The only differences are interface type (ioctl vs system call) and flexibility (range support, cross-FS capability).

When to Prefer Which Interface? #

• FICLONE: Go here first for full-file clones on the same COW filesystem. It's mature, simple, and works on older kernels (back to 3.18) compared to copy_file_range (4.5+).
• FICLONERANGE: Use this for partial file clones on the same COW filesystem—no need to copy the entire file if you only need a segment.
• copy_file_range: Choose this when you need cross-filesystem/remote support, or want a single interface that handles all copy scenarios (full/partial, COW/non-COW).

Why GNU cp Uses FICLONE Instead of copy_file_range? #

GNU cp's maintainers made this choice for a few practical reasons:

1. Backward Compatibility: FICLONE was introduced in Linux 3.18 (2014), while copy_file_range arrived in 4.5 (2016). For a tool as ubiquitous as cp, supporting older kernels is critical—FICLONE works on more legacy systems that still need COW clone support.
2. Simplicity for Common Use Cases: Most cp usage is full-file copies. FICLONE is a straightforward ioctl that only requires source/dest file descriptors, whereas copy_file_range requires specifying ranges and flags, adding extra code complexity.
3. Proven Reliability: When FICLONE launched, it was quickly adopted by major COW filesystems (Btrfs, XFS). It's a focused, mature interface for the core full-file clone use case, with simpler error handling.
4. Avoiding Flag Overhead: Using copy_file_range for COW requires setting the COPY_FILE_RANGE_COW flag, which adds conditional logic. FICLONE has no flags—it either succeeds (creates a reflink) or fails, making cp's codebase cleaner.

内容的提问来源于stack exchange，提问作者Albert