Nitesh, > 1.payload based approach: > a. Based on Mikulas patch, here a common payload is used for both source > and destination bio. > b. Initially we send source bio, upon reaching driver we update payload > and complete the bio. > c. Send destination bio, in driver layer we recover the source info > from the payload and send the copy command to device. > > Drawback: > Request payload contains IO information rather than data. > Based on past experience Christoph and Bart suggested not a good way > forward. > Alternate suggestion from Christoph was to used separate BIOs for src > and destination and match them using token/id. > As Bart pointed, I find it hard how to match when the IO split happens. In my experience the payload-based approach was what made things work. I tried many things before settling on that. Also note that to support token-based SCSI devices, you inevitably need to separate the read/copy_in operation from the write/copy_out ditto and carry the token in the payload. For "single copy command" devices, you can just synthesize the token in the driver. Although I don't really know what the point of the token is in that case because as far as I'm concerned, the only interesting information is that the read/copy_in operation made it down the stack without being split. Handling splits made things way too complicated for my taste. Especially with a potential many-to-many mapping. Better to just fall back to regular read/writes if either the copy_in or the copy_out operation needs to be split. If your stacked storage is configured with a prohibitively small stripe chunk size, then your copy performance is just going to be approaching that of a regular read/write data movement. Not a big deal as far as I'm concerned... -- Martin K. Petersen Oracle Linux Engineering
