On 13-08-23 02:33 PM, Martin K. Petersen wrote:
"Doug" == Douglas Gilbert <dgilbert@xxxxxxxxxxxx> writes:
Doug> The SCSI opcodes associated with it (0x83 and 0x84) have been
Doug> renamed THIRD PARTY COPY OUT and IN, and
Where did you see that? My SPC still has EXTENDED COPY.
SCSI _opcodes_ == SCSI operation codes. In other words the
name associated with all service actions (commands) that have
as their first byte 0x83 and 0x84 .
spc4r36h.pdf Annex F.3.1 and changed in spc4r34. Yes, well
hidden but IMO useful. So now we can use the term "Third party
copy" to cover:
- EXTENDED COPY(LID1) and associated commands
also found in SPC-2 and SPC-3 (with the "LID1" suffix)
- EXTENDED COPY(LID4) and associated commands
- the XCOPY LITE commands: POPULATE TOKEN and WRITE USING TOKEN
Doug> Confused? I certainly was.
Yeah, this is UNMAP all over again, just 100 times worse :(
Well what EXTENDED COPY (offload copy) is trying to do
ain't simple but obviously there could be a substantial
performance pay-off.
There is a "Third-party copy implementation and usage" Annex
(D) in spc4r36h.pdf . It could do with some more explanatory
text.
Anyway. Excited to see nab posting the patches! My copy offload code
from the spring has been getting stale both in the T10 and the kernel
sense. But at least we know what I'll be working on next week :)
BTW I have ported the sg_xcopy "LID1" xcopy logic into
my ddpt utility. That gives two advantages:
- can cope with ibs!=obs
- runs on OSes other than Linux
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
