On 13-08-23 04:26 AM, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger <nab@xxxxxxxxxxxxx> Hi folks! This series adds support to target-core for generic EXTENDED_COPY offload emulation as defined by SPC-4 using virtual (IBLOCK, FILEIO, RAMDISK) backends. EXTENDED_COPY is a VMWare ESX VAAI primative that is used to perform copy offload, that allows a target to perform local READ + WRITE I/O requests for bulk data transfers (cloning a virtual machine for example), instead of requiring these I/Os to actually be sent to/from the requesting SCSI initiator port.
Recently I have been looking at EXTENDED COPY since T10 has been working on it. The SCSI opcodes associated with it (0x83 and 0x84) have been renamed THIRD PARTY COPY OUT and IN, and each have several service actions. The Extended copy found in SPC-2 and SPC-3 is now termed as "LID1" (for List Identifier length of 1 byte) while the new stuff is termed "LID4" in SPC-4. The "LID4" variants are "ROD" token based. A ROD (Representation Of Data) token is 512 bytes long. sg_xcopy (written by Hannes Reinecke and found in the sg3_utils package) only supports LID1 but that covers most of the existing hardware including kit that supports VMWare ESX VAAI. As defined by T10 both EXTENDED COPY (LID1) and (LID4) do copies between disks, tapes and memory (all combinations (e.g. disk->tape) (but maybe not memory to memory). There is a stripped down version of EXTENDED COPY(LID4) that was called XCOPY LITE at one stage that only does disk to disk copies (based on a ROD token). That is the basis of Microsoft's Offload Data Transfer (ODX). It uses commands defined in SBC-3 (e.g. POPULATE TOKEN and WRITE USING TOKEN). Confused? I certainly was. Feel free to correct and clarify the above. 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
