> 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... -- Martin K. Petersen Oracle Linux Engineering -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
