Re: [PATCHv10 0/9] write hints with nvme fdp, scsi streams

[Nitesh Shetty <nj.shetty@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On 27/11/24 03:14PM, Martin K. Petersen wrote:
>
>Bart,
>
>> Submitting a copy operation as two bios or two requests means that
>> there is a risk that one of the two operations never reaches the block
>> driver at the bottom of the storage stack and hence that a deadlock
>> occurs. I prefer not to introduce any mechanisms that can cause a
>> deadlock.
>
>How do you copy a block range without offload? You perform a READ to
>read the data into memory. And once the READ completes, you do a WRITE
>of the data to the new location.
>
>Token-based copy offload works exactly the same way. You do a POPULATE
>TOKEN which is identical to a READ except you get a cookie instead of
>the actual data. And then once you have the cookie, you perform a WRITE
>USING TOKEN to perform the write operation. Semantically, it's exactly
>the same as a normal copy except for the lack of data movement. That's
>the whole point!
>
Martin

This approach looks simpler to me as well.
But where do we store the read sector info before sending write.
I see 2 approaches here,
1. Should it be part of a payload along with write ?
	We did something similar in previous series which was not liked
	by Christoph and Bart.
2. Or driver should store it as part of an internal list inside
namespace/ctrl data structure ?
	As Bart pointed out, here we might need to send one more fail
	request later if copy_write fails to land in same driver.

Thanks,
Nitesh Shetty

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]