SSC-2 Note 48, the word "record"

JoeBre at exabyte.com JoeBre at exabyte.com
Mon Mar 4 09:30:20 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* JoeBre at exabyte.com
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1C3A2.4268D790
Content-Type: text/plain;
	charset="iso-8859-1"

In the SSC-2 meeting of 2002jan14, there was an action item issued to
all participants - "All to review whether Note 48 should read "should"
or "shall" when moved into normative text."

This note's previous existence as note 31 in SSC notwithstanding, there
are serious issues with this clause. 

Note 48 reads: "NOTE 48 When compressed data is encountered on the
medium that the device is unable to decompress, the device should treat
the data as a single variable-length record. In the sense data, the
VALID bit, the ILI bit and the INFORMATION field should be set
accordingly."

Note 48 is an apparent attempt to work around a limitation of some tape
formats, wherein data that cannot be decompressed ends up being
indeterminate in size and/or block count.

Several known tape formats have compression algorithms which may
compress multiple logical blocks in a single 'compression unit'. Due to
this fact, the compressed data that the device is unable to decompress
may consist of multiple logical blocks. If the device is to treat this
data as a single variable length block, then adhering to note 48 ensures
that block numbers will be changed for every block on the medium
downstream (BOx side) of the non-decompressible data. This renumbering
of the blocks is almost certain to lead to data corruption.

Additionally, several known tape formats know the exact original
(non-compressed) size and block count in each 'compression unit',
independent of the ability to decompress the user data. For these
formats, the limitation (that note 48 is an apparent attempt to work
around) is non-existent.

Accordingly, it would seem to me that the proper behavior, rather than
note 48, is as follows: 
When compressed data is encountered on the medium that the device is
unable to decompress, the device should treat each logical block of the
data similarly to a block that cannot be read due to a permanent read
media error, i.e.: transfer all data to the initiator up to the
beginning of the first non-decompressible block; set a contingent
allegiance indicating the error (0x03, 0x11, 0x0E - CANNOT DECOMPRESS
USING DECLARED ALGORITHM?); set the VALID, ILI, and INFORMATION fields
according to the original (uncompressed) state of the block; and set the
current logical position to the following logical block, whether
decompressible or not.

This will allow the initiator to issue subsequent reads to the device,
each failing, until the non-decompressible region is exited. This
mechanism is directly analogous to the method the initiator may use to
'step' its way through a damaged area of tape, (sequence of logical
blocks with media errors).

I assert that this suggested behavior is The Right Thing To Do.
Accordingly, if any behavior is promoted to the level of normative text,
it is the behavior I have outlined that should be granted normative
status. If any tape format is incapable of this behavior, I believe it
should impinge upon that tape format's owner to advocate any other
behavior being mentioned in SSC-2.

Parenthetically, there is yet another problem with note 48.
Specifically, the text "the device should treat the data as a single
variable-length record" is ambiguous. SSC-2 does not define the term
"record" at any place in the document. Accordingly, "record" should be
replaced with "logical block".

Lastly, the word "record", used as a noun, appears exactly six times in
the text, one of them being note 48. The others are:

READ(16) p 43/59 - "Upon termination, the logical position shall be
immediately after the last recorded logical record, filemark, or setmark
(end-of-partition side)."

READ(6) p 57/73 - "Upon termination, the logical position shall be
immediately after the last recorded logical record, filemark, or setmark
(end-of-partition side)."

SPACE(6) p 60/76 - "The medium shall be positioned such that a
subsequent write operation would append to the last record, filemark, or
setmark."

SPACE(6) p 61/77 - "The medium shall be positioned such that a
subsequent write operation would append to the last record, filemark, or
setmark."

SPACE(6) p 61/77 - "Upon successful completion, the medium shall be
positioned such that a subsequent write operation would append to the
last record, filemark, or setmark."

It would appear to me that what belongs in each of these sentences is
not the word "record", but rather the term "logical block", as this has
a defined meeting that meets the criteria for each of these conditions.

Joe Breher 
Exabyte Corp 


------_=_NextPart_001_01C1C3A2.4268D790
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

SSC-2 Note 48, the word ;record; In the SSC-2 meeting of 2002jan14, there was an = action item issued to all participants - ;All to review whether = Note 48 should read ;should; or ;shall; when moved = into normative text.; This note's previous existence as note 31 in SSC = notwithstanding, there are serious issues with this clause. Note 48 reads: ;NOTE 48 When compressed data is = encountered on the medium that the device is unable to decompress, the = device should treat the data as a single variable-length record. In the = sense data, the VALID bit, the ILI bit and the INFORMATION field should = be set accordingly.; Note 48 is an apparent attempt to work around a = limitation of some tape formats, wherein data that cannot be = decompressed ends up being indeterminate in size and/or block = count. Several known tape formats have compression = algorithms which may compress multiple logical blocks in a single = 'compression unit'. Due to this fact, the compressed data that the = device is unable to decompress may consist of multiple logical blocks. = If the device is to treat this data as a single variable length block, = then adhering to note 48 ensures that block numbers will be changed for = every block on the medium downstream (BOx side) of the = non-decompressible data. This renumbering of the blocks is almost = certain to lead to data corruption. Additionally, several known tape formats know the = exact original (non-compressed) size and block count in each = 'compression unit', independent of the ability to decompress the user = data. For these formats, the limitation (that note 48 is an apparent = attempt to work around) is non-existent. Accordingly, it would seem to me that the proper = behavior, rather than note 48, is as follows: 
When compressed data is encountered on the medium = that the device is unable to decompress, the device should treat each = logical block of the data similarly to a block that cannot be read due = to a permanent read media error, i.e.: transfer all data to the = initiator up to the beginning of the first non-decompressible block; = set a contingent allegiance indicating the error (0x03, 0x11, 0x0E - = CANNOT DECOMPRESS USING DECLARED ALGORITHM?); set the VALID, ILI, and = INFORMATION fields according to the original (uncompressed) state of = the block; and set the current logical position to the following = logical block, whether decompressible or not. This will allow the initiator to issue subsequent = reads to the device, each failing, until the non-decompressible region = is exited. This mechanism is directly analogous to the method the = initiator may use to 'step' its way through a damaged area of tape, = (sequence of logical blocks with media errors). I assert that this suggested behavior is The Right = Thing To Do. Accordingly, if any behavior is promoted to the level of = normative text, it is the behavior I have outlined that should be = granted normative status. If any tape format is incapable of this = behavior, I believe it should impinge upon that tape format's owner to = advocate any other behavior being mentioned in SSC-2. Parenthetically, there is yet another problem with = note 48. Specifically, the text ;the device should treat the data = as a single variable-length record; is ambiguous. SSC-2 does not = define the term ;record; at any place in the document. = Accordingly, ;record; should be replaced with ;logical = block;. Lastly, the word ;record;, used as a noun, = appears exactly six times in the text, one of them being note 48. The = others are: READ(16) p 43/59 - ;Upon termination, the = logical position shall be immediately after the last recorded logical = record, filemark, or setmark (end-of-partition side).; READ(6) p 57/73 - ;Upon termination, the logical = position shall be immediately after the last recorded logical record, = filemark, or setmark (end-of-partition side).; SPACE(6) p 60/76 - ;The medium shall be = positioned such that a subsequent write operation would append to the = last record, filemark, or setmark.; SPACE(6) p 61/77 - ;The medium shall be = positioned such that a subsequent write operation would append to the = last record, filemark, or setmark.; SPACE(6) p 61/77 - ;Upon successful completion, = the medium shall be positioned such that a subsequent write operation = would append to the last record, filemark, or setmark.; It would appear to me that what belongs in each of = these sentences is not the word ;record;, but rather the term = ;logical block;, as this has a defined meeting that meets the = criteria for each of these conditions. Joe Breher 
Exabyte Corp 
------_=_NextPart_001_01C1C3A2.4268D790--




More information about the T10 mailing list