On Thu, Aug 19, 2021 at 12:05 AM Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > > > Native copy offload is not supported for stacked devices. > > One of the main reasons that the historic attempts at supporting copy > offload did not get merged was that the ubiquitous deployment scenario, > stacked block devices, was not handled well. > > Pitfalls surrounding stacking has been brought up several times in > response to your series. It is critically important that both kernel > plumbing and user-facing interfaces are defined in a way that works for > the most common use cases. This includes copying between block devices > and handling block device stacking. Stacking being one of the most > fundamental operating principles of the Linux block layer! > > Proposing a brand new interface that out of the gate is incompatible > with both stacking and the copy offload capability widely implemented in > shipping hardware makes little sense. While NVMe currently only supports > copy operations inside a single namespace, it is surely only a matter of > time before that restriction is lifted. > > Changing existing interfaces is painful, especially when these are > exposed to userland. We obviously can't predict every field or feature > that may be needed in the future. But we should at the very least build > the infrastructure around what already exists. And that's where the > proposed design falls short... > Certainly, on user-space interface. We've got few cracks to be filled there, missing the future viability. But on stacking, can that be additive. Could you please take a look at the other response (comment from Bart) for the trade-offs. -- Joshi
