SSC-2 Note 48, the word "record"

Dennis.W.Painter at seagate.com Dennis.W.Painter at seagate.com
Mon Mar 4 18:04:46 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Dennis.W.Painter at seagate.com
*

Hi Joe,

You are onto something here; this Mode Page F needs some cleanup.

About Note 48: I believe it is interpreted by some tape drives that the
compressed data, (an "entity", unprocessed by decompression), is
transferred to the host as though the target encountered a single variable
length block. Sense data set accordingly, ILI if the number of bytes in the
compressed entity didn't match the host command.

I have personally observed this behavior in a tape drive. In fact if the
host issued a Read variable with the byte count equal to the size of the
compressed entity then no ILI is set and no residue. Where the drive got
wrong though is in the Logical Block Address after the read. (In the sample
drive I tested the subsequent Logical Block Address was wrong)

The issue is, if Mode Page F, DDE is not set, where in the Standard does it
say that the target is to return compressed data to the host?  Maybe the
last sentence of the fifth paragraph tries to speak to this but it:
"Uncompressed data shall be unaffected by the setting of the DDE bit" This
is vague at best and to me should either be deleted or changed to be
specific. If compressed data is affected, how?

Paragraph ten may also hint that compressed data will be sent to the host
with the words: "... when data is encountered on the medium during a read
operation that requires different handling by the application client than
the data most recently encountered during a prior read operation. At each
of these boundaries, the data that is sent to the application client is of
a fundamentally different nature from that which was previously sent..."
This all presented in the context of the RED setting being one. What make a
RED setting of one warrant this sentence?

I tend to favor defining the behavior such that the entire entity is sent
to the host (within the limits of the Read command), and that the target
sets its logical block position to the next block past the entity. If the
target cannot determine logical position anywhere past the entity then the
target is stuck at the last good read location. I favor this because upon
getting a media error the host should Read Position to ensure
synchronization with the target.

If the Standard is clarified and or changed to require the host to read
through the compressed data one block at a time then I do not believe that
the target should be required to return the entity. I say this because what
happens if a host issues a Locate or Space command that ends up in the
middle of an entity, (With a Locate to that position I would not expect an
error), and follows said Locate command with a Read command?  Can't give
the host part of the entity. We can make the host read through a block at a
time.

(Filemarks make Spacing into an entity pretty ugly, as is Locating into an
entity followed by a Write command)


There are also other issues I have with the Standard for Mode Page F.

If DDE is not set is the target to respond as if there are NO supported
algorithms? I have always taken that to be the case because if DDE is not
set and RED is zero, (the default for drives I have seen), then the target
will send the entity to the host without a check condition. This is per the
second row of Table 59.

No default is specified for RED. It might be critical if entity data is
going to be sent to the host.

One more; Paragraph thirteen states "The logical position shall be on the
EOP side of the encountered data..." but I think the original authors did
not consider Read Reverse.

Bye,
Dennis Painter
Seagate Removable Storage Solutions.





JoeBre at exabyte.com@t10.org on 03/04/2002 09:30:20 AM

Sent by:  owner-t10 at t10.org


To:   t10 at t10.org
cc:   RogerR at boulderpost.exabyte.com, fredm at boulderpost.exabyte.com,
       bradg at boulderpost.exabyte.com, TravisB at boulderpost.exabyte.com

Subject:  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



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




More information about the T10 mailing list