SG_XCOPY(8) | SG3_UTILS | SG_XCOPY(8) |
sg_xcopy - copy data to and from files and devices using SCSI EXTENDED COPY (XCOPY)
sg_xcopy [bs=BS] [conv=CONV] [count=COUNT] [ibs=BS] [if=IFILE] [iflag=FLAGS] [obs=BS] [of=OFILE] [oflag=FLAGS] [seek=SEEK] [skip=SKIP] [--help] [--version]
[app=0|1] [bpt=BPT] [cat=0|1] [dc=0|1] [fco=0|1] [id_usage={hold|discard|disable}] [list_id=ID] [prio=PRIO] [time=0|1] [verbose=VERB] [--on_dst|--on_src] [--verbose]
Copy data to and from any files. Specialized for "files" that are Linux SCSI devices that support the SCSI EXTENDED COPY (XCOPY) command.
This utility has similar syntax and semantics to dd(1) but with no "conversions" is supported.
The first group in the synopsis above are "standard" Unix dd(1) operands. The second group are extra options added by this utility. Both groups are defined below in combined, alphabetical order.
By default the XCOPY command is sent to OFILE. This can be changed with the --on_src or iflag=xflag options which cause the XCOPY command to be sent to IFILE instead. Also see the section on ENVIRONMENT VARIABLES.
In the SPC-4 standard the T10 committee has expanded the XCOPY command so that it now has two variants: "LID1" (for a List Identifier length of 1 byte) and "LID4" (for a List Identifier length of 4 bytes). This utility supports the older, LID1 variant which is also found in SPC-3 and earlier. While the LID1 variant in SPC-4 is command level (binary) compatible with XCOPY as defined in SPC-3, some of the command naming has changed. This utility uses the older, SPC-3 XCOPY names.
The ddpt utility supports the same xcopy(LID1) functionality as this utility with the same options and flags. Additionally ddpt supports a subset of xcopy(LID4) functionality variously called "xcopy version 2, lite" or ODX. ODX is a market name and stands for Offloaded Data Xfer (i.e. transfer).
Here is a list of flags and their meanings:
The pad and cat bits control the handling of residual data. As the data can be specified either in terms of source or target logical block size and both might have different block sizes residual data is likely to happen in these cases. If both logical block sizes are identical these bits have no effect as residual data will not occur.
If none of these bits are set, the EXTENDED COPY command will be aborted with additional sense 'UNEXPECTED INEXACT SEGMENT'.
If only the cat bit is set the residual data will be retained and made available for subsequent segment descriptors. Residual data will be discarded for the last segment descriptor.
If the pad bit is set for the source descriptor only, any residual data for both source or destination will be discarded.
If the pad bit is set for the target descriptor only any residual source data will be handled as if the cat bit is set, but any residual destination data will be padded to make a whole block transfer.
If the pad bit is set for both source and target any residual source data will be discarded, and any residual destination data will be padded.
If the command line invocation does not explicitly (and unambiguously) indicate whether the XCOPY SCSI command should be sent to IFILE (i.e. the source) or OFILE (i.e. the destination) then a check is made for the presence of the XCOPY_TO_SRC and XCOPY_TO_DST environment variables. If either one exists (but not both) then it indicates where the SCSI XCOPY command will be sent. By default the XCOPY command is sent to OFILE.
Here are some retired options that are still present:
Copying data behind an Operating System's back can cause problems.
In the case of Linux, users should look at this link:
http://linux-mm.org/Drop_Caches
This command sequence may be useful:
sync; echo 3 > /proc/sys/vm/drop_caches
Various numeric arguments (e.g. SKIP) may include multiplicative suffixes or be given in hexadecimal. See the "NUMERIC ARGUMENTS" section in the sg3_utils(8) man page.
The COUNT, SKIP and SEEK arguments can take 64 bit values (i.e. very big numbers). Other values are limited to what can fit in a signed 32 bit number.
All informative, warning and error output is sent to stderr so that dd's output file can be stdout and remain unpolluted. If no options are given, then the usage message is output and nothing else happens.
If a device supports xcopy operations then it should set the 3PC field (3PC stands for Third Party Copy) in its standard INQUIRY response. This utility will attempt a xcopy operation irrespective of the value in the 3PC field but if it is zero (cleared) one would expect the xcopy operation to fail.
The status of the SCSI EXTENDED COPY command can be queried with sg_copy_results(sg3_utils)
Currently only block-to-block transfers are implemented; IFILE and OFILE must refer to a SCSI block device.
No account is taken of partitions so, for example, /dev/sbc2, /dev/sdc, /dev/sg2, and /dev/bsg/3:0:0:1 would all refer to the same thing: the whole logical unit (i.e. the whole disk) starting at LBA 0. So any partition indication (e.g. /dev/sdc2) is ignored. The user should set SKIP, SEEK and COUNT with information obtained from a command like 'fdisk -l -u /dev/sdc' to account for partitions.
XCOPY (LID1) capability has been added to the ddpt utility which is in a package of the same name. The ddpt utility will run on other OSes (e.g. FreeBSD and Windows) while sg_xcopy only runs on Linux. Also ddpt permits the arguments to ibs= and ibs= to be different.
Copy 2M of data from the start of one device to another:
# sg_xcopy if=/dev/sdo of=/dev/sdp count=2048 list_id=2 dc=1
sg_xcopy: if=/dev/sdo skip=0 of=/dev/sdp seek=0 count=1024
Start of loop, count=1024, bpt=65535, lba_in=0, lba_out=0
sg_xcopy: 1024 blocks, 1 command
Check the status of the EXTENDED COPY command:
# sg_copy_results --status --list_id=2 /dev/sdp
Receive copy results (copy status):
Held data discarded: Yes
Copy manager status: Operation completed without errors
Segments processed: 1
Transfer count units: 0
Transfer count: 0
The signal handling has been borrowed from dd: SIGINT, SIGQUIT and SIGPIPE output the number of remaining blocks to be transferred and the records in + out counts; then they have their default action. SIGUSR1 causes the same information to be output yet the copy continues. All output caused by signals is sent to stderr.
The exit status of sg_xcopy is 0 when it is successful. Otherwise see the sg3_utils(8) man page.
An additional exit status of 90 is generated if the flock flag is given and some other process holds the advisory exclusive lock.
Written by Hannes Reinecke and Douglas Gilbert.
Report bugs to <dgilbert at interlog dot com>.
Copyright © 2000-2019 Hannes Reinecke and Douglas Gilbert
This software is distributed under the GPL version 2. There is NO warranty;
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
There is a web page discussing sg_dd at http://sg.danny.cz/sg/sg_dd.html
A POSIX threads version of this utility called sgp_dd is in the sg3_utils package. Another version from that package is called sgm_dd and it uses memory mapped IO to speed transfers from sg devices.
The lmbench package contains lmdd which is also interesting. For moving data to and from tapes see dt which is found at http://www.scsifaq.org/RMiller_Tools/index.html
To change mode parameters that effect a SCSI device's caching and error recovery see sdparm(sdparm)
See also dd(1), sg_copy_results(sg3_utils), ddrescue(GNU), ddpt,ddptctl(ddpt)
February 2019 | sg3_utils-1.45 |