Copy Offload

### Overview This session addresses the long-standing challenge of implementing copy offload in the Linux block layer storage stack—a problem actively discussed and iterated upon for roughly six to eight years. The primary goal is establishing a standardized block layer interface that enables user space (via ioctl or io_uring) and file systems to push copy offload operations directly down the storage stack to major protocols like NVMe and SCSI. The discussion centers on the current architectural direction, challenges with stacking drivers like Device Mapper (DM), and how to reliably test the plumbing without specialized hardware.

### Key Topics - **Evolution of Copy Offload Interfaces:** Moving from single-request opcode implementations (and their bio-splitting issues) to a token-based, two-request opcode model (`REQ_OP_IN` and `REQ_OP_OUT`) originated by Mikuláš/Nicholas to support concurrency and DM integration. - **Recent Patch Proposals:** Recent work posted by Samsung introducing generic block layer copy opcodes, multi-source/destination interfaces, DM linear support without splitting, emulation fallbacks, and integration into ZoneFS, `copy_file_range`, and DM kcopyd. - **Device Mapper (DM) Challenges:** Complications around bio splitting, DM partial bios, target constraints (such as dm-thin chunk sizes), arbitrary remapping, and incompatible targets (such as dm-crypt due to per-sector IV/key derivation). - **Testing Plumbing and Harnesses:** The critical lack of test coverage across upstream kernels and distros, with proposals for loopback emulation using file system `copy_file_range`, memory-backed `null_blk`, and in-kernel NVMe Target loop devices.

### Technical Details - **Two-Opcode / Token-Based Design:** Instead of issuing a single extended copy command, a token-based approach submits a first request opcode (`REQ_OP_IN`) where the low-level driver or controller saves the range metadata. A subsequent request opcode (`REQ_OP_OUT`) referencing the prior token executes the controller-level offload. This avoids denial-of-service issues when intermixing copy offloads with standard read and write workloads. - **Bio Splitting Dilemma:** Copy offload ranges (offsets and lengths) are currently embedded in the bio's data payload rather than standard bio header fields, preventing standard bio splitting from functioning properly. When stacking drivers or DM targets (e.g., dm-linear spanning multiple physical disks or targets using `dm_accept_partial_bio`) require splits, the operation currently fails or must fall back to software emulation. - **Device Mapper Targets & Crypto:** Participants noted that targets like dm-crypt inherently cannot work with native copy offload because sector offsets serve as seeds for encryption keys; moving data across sectors without host interaction leaves ciphertext that cannot be properly decrypted. - **Driver and Target Emulation for Testing:** Because physical NVMe or SCSI drives with copy offload support are rare among developers, attendees agreed on creating test implementations: using loopback wired to file system `copy_file_range`, a memory-backed `null_blk` driver for integration into `blktests`, and a file-backed NVMe Target loopback configuration.

### Takeaways The consensus indicates that before upstream adoption can progress, the patch authors must address Device Mapper integration beyond basic `kcopyd` and dm-linear, specifically investigating whether bio splitting can inspect bio payloads or gracefully handle remapping. Crucially, patch authors need to provide software-emulated test harnesses (loopback with `copy_file_range`, `null_blk`, and `blktests`/`fstests` test cases) to allow community review and automated testing across Linux distributions.