On 01/08/2015 03:11 PM, Douglas Gilbert wrote:
Andy,
XCOPY is huge and keeps getting bigger (apart from the recent
trimming of the "LID1" generation mentioned above). Most SCSI
commands are sent to the LU involved, but for EXTENDED COPY
command itself, should it be sent to the source or destination
of the copy, or another LU which acts as a third party copy
manager? Also when you examine the parameter block associated
with the EXTENDED COPY command, one starts thinking there
must be a cleaner and simpler way.
In the real world VMware have been using the basic disk->disk
XCOPY for around 10 years. Their usage seems to be dominant in
the market place.
While the LID4 rewrite/additions were occurring at T10 in 2011,
a proposal was made to simplify things with a two step,
disk-to-disk copy. The glue between those two steps is a token.
The first step (POPULATE TOKEN) is sent to the copy source **,
the second step is sent to the copy destination (WRITE USING
TOKEN). The document is called:
XCOPYv2: Extended Copy Plus & Lite
[11-077R1 at www.t10.org] and is worth looking at. The
"Bucket Of Bytes" (BOB) in that document has become the
"Representation Of Data" (ROD) found in T10 documents today.
Commercially MS and NetApp (seemingly) were behind this
new approach. And MS christened it ODX which is found in their
recent OS products.
I have written this page about the ddpt utility's
implementation of these two disk-to-disk copy approaches:
http://sg.danny.cz/sg/ddpt_xcopy_odx.html
Thanks for your and nab's reply and this web page, they answer all my
questions. I was failing to find anything on MS or vendor sites with
this kind of info.
Thanks again -- Andy
--
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
