On 11/29/24 15:19, Christoph Hellwig wrote: > On Thu, Nov 28, 2024 at 05:51:52PM +0900, Damien Le Moal wrote: >>> Maybe. But you'll have a hard time convincing me to add any kind of >>> state machine or bio matching magic to the SCSI stack when the simplest >>> solution is to treat copying like a read followed by a write. There is >>> no concurrency, no kernel state, no dependency between two commands, nor >>> two scsi_disk/scsi_device object lifetimes to manage. >> >> And that also would allow supporting a fake copy offload with regular >> read/write BIOs very easily, I think. So all block devices can be >> presented as supporting "copy offload". That is nice for FSes. > > Just as when that showed up in one of the last copy offload series > I'm still very critical of a stateless copy offload emulation. The > reason for that is that a host based copy helper needs scratch space > to read into, and doing these large allocation on every copy puts a > lot of pressure onto the allocator. Allocating the buffer once at > mount time and the just cycling through it is generally a lot more > efficient. Sure, that sounds good. My point was that it seems that a token based copy offload design makes it relatively easy to emulate copy in software for devices that do not support copy offload in hardware. That emulation can certainly be implemented using a single buffer like you suggest. -- Damien Le Moal Western Digital Research
