Bart, > There are some strong arguments in this thread from May 2024 in favor of > representing the entire copy operation as a single REQ_OP_ operation: > https://lore.kernel.org/linux-block/20240520102033.9361-1-nj.shetty@xxxxxxxxxxx/ As has been discussed many times, a copy operation is semantically a read operation followed by a write operation. And, based on my experience implementing support for both types of copy offload in Linux, what made things elegant was treating the operation as a read followed by a write throughout the stack. Exactly like the token-based offload specification describes. > Token-based copy offloading (called ODX by Microsoft) could be > implemented by maintaining a state machine in the SCSI sd driver I suspect the SCSI maintainer would object strongly to the idea of maintaining cross-device copy offload state and associated object lifetime issues in the sd driver. > I'm assuming that the IMMED bit will be set to zero in the WRITE USING > TOKEN command. Otherwise one or more additional RECEIVE ROD TOKEN > INFORMATION commands would be required to poll for the WRITE USING TOKEN > completion status. What would the benefit of making WRITE USING TOKEN be a background operation? That seems like a completely unnecessary complication. > I guess that the block layer maintainer wouldn't be happy if all block > drivers would have to deal with three or four phases for copy > offloading just because ODX is this complicated. Last I looked, EXTENDED COPY consumed something like 70 pages in the spec. Token-based copy is trivially simple and elegant by comparison. -- Martin K. Petersen Oracle Linux Engineering
