[LSF/MM/BPF TOPIC] Block storage copy offloading

[Bart Van Assche]

On 2/4/26 3:58 PM, Keith Busch wrote:
> On Fri, Jan 23, 2026 at 02:19:44PM -0800, Bart Van Assche wrote:
>> Adoption of zoned storage is increasing in mobile devices. Log-
>> structured filesystems are better suited for zoned storage than
>> traditional filesystems. These filesystems perform garbage collection.
>> Garbage collection involves copying data on the storage medium.
>> Offloading the copying operation to the storage device reduces energy
>> consumption. Hence the proposal to discuss integration of copy
>> offloading in the Linux kernel block, SCSI and NVMe layers.
>>
>> Other use-cases for copy offloading include reducing network traffic in
>> NVMeOF setups while copying data and also increasing throughput while
>> copying data.
> 
> I'm interested in the topic. I'm just not sure about the approach. If it
> doesn't support vectored sector sources, then it's much less
> interesting. From the host point of view, I'd like to be able to submit
> arbitrarily large bio's to the block layer that can be split and merged
> for optimal alignment to hardware limits. The two-bio approach looks
> overly complicated with respect to that.

Hi Keith,

How about supporting vectored sources with this approach:
* Copy requests with multiple discontiguous input or output ranges
   are submitted as multiple bios - one bio for each contiguous range.
* Before these multiple bios are submitted, blk_start_plug() is called.
   After these have been submitted blk_finish_plug() is called.
* After device mapper LBA translation has completed for all involved
   bios, if all involved bios apply to the same input and output
   block devices, and if sufficient requests are available, the block
   layer submits all the translated requests at once to the block driver
   by calling a new callback pointer that is added in struct blk_mq_ops.
* The block driver is responsible for combining the discontiguous
   requests into a single copy offload command (if permitted by the
   device limits).

Thanks,

Bart.