[PATCH 0/5] block: another block copy offload

[Bart Van Assche]

On 5/21/25 3:31 PM, Keith Busch wrote:
> From: Keith Busch <kbusch at kernel.org>
> 
> I was never happy with previous block copy offload attempts, so I had to
> take a stab at it. And I was recently asked to take a look at this, so
> here goes.
> 
> Some key implementation differences from previous approaches:
> 
>    1. Only one bio is needed to describe a copy request, so no plugging
>       or dispatch tricks required. Like read and write requests, these
>       can be artbitrarily large and will be split as needed based on the
>       request_queue's limits. The bio's are mergeable with other copy
>       commands on adjacent destination sectors.
> 
>    2. You can describe as many source sectors as you want in a vector in
>       a single bio. This aligns with the nvme protocol's Copy implementation,
>       which can be used to efficiently defragment scattered blocks into a
>       contiguous destination with a single command.
> 
> Oh, and the nvme-target support was included with this patchset too, so
> there's a purely in-kernel way to test out the code paths if you don't
> have otherwise capable hardware. I also used qemu since that nvme device
> supports copy offload too.

Before any copy offloading code is merged in the upstream kernel, a plan
should be presented for how this partial implementation will evolve into
a generic solution. As Hannes already pointed out, support for
copying between block devices is missing. SCSI support is missing.
Device mapper support is missing. What is the plan for evolving this
patch series into a generic solution? Is it even possible to evolve this
patch series into a generic solution?

Thanks,

Bart.