3 XCOPY problems

Joseph C. Nemeth jnemeth at concentric.net
Thu May 20 11:42:48 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* "Joseph C. Nemeth" <jnemeth at concentric.net>
*
I'm sorry, Steve, I got confused in my explanation, and mis-expressed the
whole issue. You are correct. Let me try again.

Here's a typical example of the normal use of padding:

Src (disk), block=512, pad=0
Dst (tape), block=65536, pad=1
Segment 1: type 00h, cat=1, addr=A1, count=N1
...
Segment N: type 00h, cat=0, addr=AN, count=NN

With type 00h (disk to tape) copies, the source (disk) controls the
transfer count, and the tape writes as many records in each segment as
necessary to keep up. Data is collected, serialized, and reblocked onto the
tape. On the final copy segment, the last 64K tape block is padded to the
64K boundary with zeros, and flushed to tape. Note that when the SOURCE
controls the count, we are using DESTINATION padding.

Src (tape), block=65536, pad=1
Dst (disk), block=512, pad=0
Segment 1: type 01h, cat=1, addr=A1, count=N1
...
Segment N: type 01h, cat=0, addr=AN, count=NN

With type 01h (tape to disk) copies, the destination (disk) controls the
transfer count, and the tape reads as many records in each segment as
necessary to fill the write requests. Data is retrieved from the tape,
reblocked, and restored to the original disk locations. The last 64K tape
block may contain excess (pad) data, which is stripped. This is entirely
appropriate, because the data being stripped by the copy manager is the
original pad data added by the copy manager. Note that  when the
DESTINATION controls the count, we are using SOURCE padding. 

Because the device being padded is NOT the device controlling the transfer
count, the transfer count for the padded device is something chosen by the
copy manager, not the host, and represents excess data generated and
stripped by the copy manager because of its reblocking requirements.

The problem arises when the device being padded IS the device controlling
the transfer count. I can't think of any reason on earth (or otherwise) to
do this, but it is legal according to the standard.

Take the first example, with the pad bits swapped:

Src (disk), block=512, pad=1
Dst (tape), block=65536, pad=0
Segment 1: type 00h, cat=1, addr=A1, count=N1
...
Segment N: type 00h, cat=0, addr=AN, count=NN

If we assume that this ends with an inexact segment, we are forced to first
read data from the disk, and then discard at least some of it, rather than
writing it to tape, and NOT report this as an error condition. Granted,
this is a blunder on the part of the program that built this XCOPY
descriptor, but I don't think it would be a discourtesy to inform the
program of its mistake by reporting an UNEXPECTED INEXACT SEGMENT at the
end of this sequence, when we discard the data. We KNOW that the data being
discarded is NOT pad data generated by the copy manager -- it is real data
of some sort we read from the device controlling the transfer count, and
discarding it should be a copy error.

If we take the second example, and swap the pad bits, the problem is even
worse:

Src (tape), block=65536, pad=0
Dst (disk), block=512, pad=1
Segment 1: type 01h, cat=1, addr=A1, count=N1
...
Segment N: type 01h, cat=0, addr=AN, count=NN

When we read the final (inexact) tape block, we have a whole bunch of data
left over after writing a portion of it to the disk. What do we do with it?
We're told to pad it to a destination block size with zeros, which only
generates MORE data we don't know what to do with. We don't even have the
excuse (as above) of being told to discard source data, and MUST therefore
report some kind of error, which I assume would be UNEXPECTED INEXACT SEGMENT.

At 10:23 AM 5/20/99 , you wrote:
>
>Joseph,
>
>As far as the pad usage is concerned, the behavior described in Table 23,
>src pad=1, dst pad=0, cat =0 , when a transfer is enacted, specifies that
>the src pad bit defines source "stripping" when the source transfer length
>for the segment is larger than the destination transfer length. Even though
>the source transfer length is a multiple of the source block size, I
>understand the source padding bit to have another use, which is the
>stripping of data that cannot be transfered to the destination block(s).
>Therefore, in this case I would not consider the src pad bit to be a no-op.
>
>One could make an argument as to whether the behavior I described is useful.
>
>steve
>
>Steve Wilson steve at crossroads.com
>T 512.794.2716	  F 512.349.0304
>"Routing Infinibytes" 
>Crossroads Systems    Austin, Texas 


Joseph C. Nemeth          Precision Algorithms          (970) 226-5427
contact:                         Spectra Logic                    (303)
449-6400x1102

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list