XCOPY inexact segments and cat

Joseph C. Nemeth jnemeth at concentric.net
Tue May 18 14:51:43 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* "Joseph C. Nemeth" <jnemeth at concentric.net>
*
There is an implementation-related problem in the current T10/99-163r1
relating to inexact segments and cat. I would like to suggest a change to
the language describing the use of the 'cat' bit.

In Table 23, cat bit 1, it states "On inexact segments, the remainder of
the destination block data shall be taken from the next segment." I suggest
this be changed to "On inexact segments, the remainder of the source block
data shall be contributed to the next segment."

The current wording results in some insuperable difficulties when
attempting to implement it as stated.

When performing a 'cat' transfer for an inexact segment, the Read operation
can conceptually result in either an "overrun" or an "underrun" condition
relative to the subsequent Write operation -- an "overrun" occurs when more
data is read for the segment than is allowed to be written, causing excess
source data to spill over into the next segment, while an "underrun" occurs
when less data is read for the segment than is required to be written,
forcing additional source data to be acquired from the next segment.

The current language requires the copy manager to always end each inexact
segment in an underrun condition. This cannot always be done. The proposed
change requires the copy manager to end each inexact segment in an overrun
condition, which can always be done.

As an example, consider a source tape with STREAM BLOCK LENGTH=0, FIXED=0,
SILI=1, performing a type 01h transfer (where the disk==destination block
count drives the transfer). Conceptually, we are trying to fill a "mold"
(the disk blocks) from a "crucible" full of bits (the tape blocks), and are
trying to ignore the structure of the tape. If the tape actually contains
records that are smaller than the STREAM DEVICE TRANSFER LENGTH, the target
implementation has two choices: a) continue reading from the tape until a
(minimal) overrun condition occurs, resulting in extra source data that
needs to be contributed to the next segment, or b) read a fixed count of
tape records, computed from the destination block size and count, and the
stream device transfer length, resulting in a (possibly non-maximal) underrun.

Option a) seems to be the appropriate way to do this, but violates the
language of the standard. Option b) can lead to all sorts of interesting
copy problems. For instance, suppose the host specifies a STREAM TRANSFER
LENGTH of 256K, but the tape actually has 12K records. Under option b), the
first segment will have to draw its data from not just the next segment,
but from the next *21* segments. On each subsequent segment, the spread
between source and destination segments gets worse. I cannot imagine that
this behavior is what is intended.

There will be a subtle change in the behavior of the device if the language
is changed. Here are two examples of different results from the change in
wording.

A) Tape destinations where tape write size varies from segment to segment:

src (disk) block size 1K, src pad=0; dst (tape) block size 0, dst pad=0
Segment 1: type 00h, tape length=64K, disk block count=32, cat=1
Segment 2: type 00h, tape length=32K, disk block count=32, cat=1
Segment 3: type 00h, tape length=16K, disk block count=32, cat=1
Segment 4: type 00h, tape length=32K, disk block count=32, cat=1

As the standard currently reads, this should result in the following
written to tape:
1 x 64K (read using segments 1 & 2, write using segment 1)
	   (write using segment 2 skipped, source data already exhausted)
2 x 16K (read using segment 3, write using segment 3)
1 x 32K (read using segment 4, write using segment 4)

Under the proposed change, this will result in:
	   (write using segment 1 skipped, not enough data)
2 x 32K (read using segments 1 & 2, write using segment 2)
2 x 16K (read using segment 3, write using segment 3)
1 x 32K (read using segment 4, write using segment 4)

B) Disk-to-disk transfers involving serialization and reblocking:

src (disk) block size 1K, src pad=0; dst (MO disk) block size 2K, dst pad=1
Segment 1: type 02h, cat=1, DC=0, block count=15, src addr=1000, dst addr=5000
Segment 2: type 02h, cat=1, DC=0, block count=17, src addr=3000, dst addr=5008
...

As the standard currently reads, this should result in the following:
src blocks 1000...1014, 3000 -> dst blocks 5000...5007
src blocks 3001...3017 -> dst blocks 5008...5015

Under the proposed change, this will result in:
src blocks 1000...1013 -> dst blocks 5000...5006
src blocks 1014, 3000...3017 -> dst blocks 5008...5016

Especially in this latter case, both the SCSI initiator of the XCOPY
command, and the target XCOPY manager, must agree on exactly how to handle
this inexact segment condition, since they need to agree on whether the
destination block address should be 5007 or 5008 to result in the desired
behavior.

*
* 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