[PATCHv10 0/9] write hints with nvme fdp, scsi streams
Nitesh Shetty
nj.shetty at samsung.com
Thu Dec 5 00:03:42 PST 2024
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
More information about the Linux-nvme
mailing list