SSC-2 Note 48, the word "record"

JoeBre at exabyte.com JoeBre at exabyte.com
Wed Mar 6 09:24:54 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_01C1C533.D47313C0
Content-Type: text/plain;
	charset="iso-8859-1"

We do not claim support for DDE=0. In reading your reply, I can see that
my vision on this issue was somewhat myopic due to this fact. Below is
further discussion, hopefully from the viewpoint of seeing the whole
picture on my part.

> -----Original Message----- 
> From: Dennis.W.Painter at seagate.com 
> Subject: Re: SSC-2 Note 48, the word "record" 
> 
> 
> 
> 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 believe that what you describe is precisely the behavior specified in
SSC-2's note 48 (SSC's note 31). As I will expound below, however, I
believe that this is inappropriate behavior in regards to system level
operations.

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

If I understand your point, note 48 *mandates* that the LBA will be
'wrong' for the case of any non-decompressible 'entities' ('compression
units', or 'records' in the note) that consist of more than one logical
block. Once again, this is likely to be catastrophic behavior from a
system level viewpoint.

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

I believe that the only clauses that speak to the issue of returning
non-decompressible data to the initiator may be note 48, and the
paragraph outlining the behavior of RED=1 (as you point out below).

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

I believe that this last sentence of paragraph five is clear. I believe
that it is mute on the point of whether the device is to return
compressed data to the host. I read it as if there is a difference
between 'uncompressed' and 'decompressed'. I interpret 'uncompressed' to
mean data that has *not* been written to media in compressed form. As
such, I believe that his sentence says that: for any data that has been
stored on tape in uncompressed form, the reading of this data is
unaffected by the setting of the DDE bit.

> If compressed data is affected, how? 

My interpretation is: DDE=1 indicates the drive is to attempt to
decompress any compressed data it reads from the media. Any data read
and decompressed is to be returned to the initiator (as per FIXED, xfer
length, etc.) in decompressed form. Any failure to decompress will yield
a CHECK CONDITION. DDE=0 indicates the drive is *not* to attempt to
decompress any compresssed data it reads from the media. I believe the
intent is that the device should send all non-decompressed read data to
the initiator, but I suppose it *could* be argued that this is not
specified behavior. Perhaps this is an opportune place to speak to the
issue of returning non-decompressed data to the initiator.

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

The processing that changes from RED=0 to RED=1 is the processing for
the transitions from: reading compressed data that was compressed with
an unsupported algorithm (non-decompressible data) to reading
uncompressed data; and reading non-decompressible data to reading
decompressible data. The only benefit that I see in this reporting is
for the case of DDE=0. This would inform the initiator that it needs to
treat the data transferred to it by the device in a different manner
than the Prior Data - i.e. stop employing software decompression within
the inititor, or change the software decompression algorithm. Perhaps we
should make this explicit. However, for this to be useful, I believe
that there are other boundaries that need to be reported. I believe that
in essence, all the boundaries need to generate a CHECK CONDITION, as
per the case for RED=2, as the initiator will need to employ a different
decompression algorithm upon crossing each boundary.

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

I would agree that this would be acceptable behavior iff DDE=0. I would
still prefer that each 'entity' be a single logical block, but you may
be able to convince me otherwise. At bare minimum, the LBAs of blocks
downstream of the 'entity' should not be altered.

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

We are in agreement on this. As I alluded above, my original post did
not properly consider the case of DDE=0. I believe the behavior I
originally posted, and that you mention in the paragraph above, is the
only appropriate behavior for the case of DDE=1.

I have yet to encounter a 'real world host' which sets DDE=0. Typical
'hosts' trust the drive to get the compression/decompression right. As
such, they employ no unique error handling for decompression errors, as
opposed to generic permanent read media errors. As such, my intent for
the case of encountering non-decompressible data, when DDE=1, is to
allow the initiator to employ the same error recovery/defect skipping
algorithm as would be employed in the presence of a permanent read media
error.

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

If DDE=1, the logical block that is at that location should be returned
to the initiator. In the general case, this may require the 'physical'
read operation to start at some point before the desired LBA, in order
for the decompression hardware to be able to decompress an entire
'compression unit'. Note that this does not preclude returning the
precise logical block the initiator positioned to.

I would guess the proper thing in the case of DDE=0 would be to return a
CHECK CONDITION. This is due to the fact that it is nonsensical to
locate a logical boundary within compressed data. (caveat below)

  
> Can't give 
> the host part of the entity. 

I suppose there are some heroic iterative steps the drive could invoke
to map logal boundaries to some byte location within the compressed
data, but this still could not be employed for any unsupported
algorithm.

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

Yes, it can be complex. However, at least in the case of DDE=1, this has
been a routine requirement for quite a while. 

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

As I mentioned earlier, we do not claim support for DDE=0. Similarly, we
claim support for only RED=0. As such, our defaults are different from
yours. Your interpretation of DDE=0 causing all algorithms to be treated
as unsupported seems eminently sensible to me. 

There seems to be a larger question, however. If a drive does not
support a given compression algorithm, how is it to distinguish between
an 'entity' encoded with that unsupported algorithm, and data read with
an uncorrectable read error? In our case, if we can read a 'physical
block' from the medium, (along with any associated physical blocks that
are part of the same 'compression unit'), yet we are unable to
decompress the data, there are exactly three factors which could cause
that error: The decompression hardware is broken, in which case the
proper thing to do is to not return that data, but rather return CHECK
CONDITION - Hardware Error, or; One or more bits of the 'physical block'
in our buffer have changed state after reading them from the medium,
with the same result as the previous case (after internal retries fail),
or; The 'physical block' had a pathological pattern of bits in error
which caused the error detection portion of our ECC algorithm to let the
error pass undetected (a vanishingly small probability, but admittedly a
mathematical possibility), in which case the proper thing to do would be
to not return the data, but rather issue a CHECK CONDITION - Permanent
Read Error (after internal retries, of course). Note that in each of
these cases, it is nonsensical to return the data to the initiator.

Somehow, I cannot understand what possible use an initiator might make
of any data transferred to it, under the case of DDE=0, RED=0, and a
boundary is crossed from uncompressed to compressed. If a CHECK
CONDITION accompanied the data, then a sophisticated inititator could
presumably decompress the data itself. However, if the data is returned
without any indication that the data is now in compressed form, it has
no way of knowing that it needs to process the new logical block with
its own decompression. It seems to me that this is certain to result in
a failed restore operation, as the data it is getting back is *not* the
data it sent when writing.

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

Agreed. Neither did I. 

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


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

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

 RE: SSC-2 Note 48, the word ;record; We do not claim support for DDE=3D0. In reading your = reply, I can see that my vision on this issue was somewhat myopic due = to this fact. Below is further discussion, hopefully from the viewpoint = of seeing the whole picture on my part. > -----Original Message----- 
> From: Dennis.W.Painter at seagate.com 
> Subject: Re: SSC-2 Note 48, the word = ;record; 
> 
> 
> 
> 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 believe that what you describe is precisely the = behavior specified in SSC-2's note 48 (SSC's note 31). As I will = expound below, however, I believe that this is inappropriate behavior = in regards to system level operations.   
> 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) If I understand your point, note 48 *mandates* that = the LBA will be 'wrong' for the case of any non-decompressible = 'entities' ('compression units', or 'records' in the note) that consist = of more than one logical block. Once again, this is likely to be = catastrophic behavior from a system level viewpoint. > 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? I believe that the only clauses that speak to the = issue of returning non-decompressible data to the initiator may be note = 48, and the paragraph outlining the behavior of RED=3D1 (as you point = out below). >  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. I believe that this last sentence of paragraph five = is clear. I believe that it is mute on the point of whether the device = is to return compressed data to the host. I read it as if there is a = difference between 'uncompressed' and 'decompressed'. I interpret = 'uncompressed' to mean data that has *not* been written to media in = compressed form. As such, I believe that his sentence says that: for = any data that has been stored on tape in uncompressed form, the reading = of this data is unaffected by the setting of the DDE bit. > If compressed data is affected, how? My interpretation is: DDE=3D1 indicates the drive is = to attempt to decompress any compressed data it reads from the media. = Any data read and decompressed is to be returned to the initiator (as = per FIXED, xfer length, etc.) in decompressed form. Any failure to = decompress will yield a CHECK CONDITION. DDE=3D0 indicates the drive is = *not* to attempt to decompress any compresssed data it reads from the = media. I believe the intent is that the device should send all = non-decompressed read data to the initiator, but I suppose it *could* = be argued that this is not specified behavior. Perhaps this is an = opportune place to speak to the issue of returning non-decompressed = data to the initiator. > 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? The processing that changes from RED=3D0 to RED=3D1 = is the processing for the transitions from: reading compressed data = that was compressed with an unsupported algorithm (non-decompressible = data) to reading uncompressed data; and reading non-decompressible data = to reading decompressible data. The only benefit that I see in this = reporting is for the case of DDE=3D0. This would inform the initiator = that it needs to treat the data transferred to it by the device in a = different manner than the Prior Data - i.e. stop employing software = decompression within the inititor, or change the software decompression = algorithm. Perhaps we should make this explicit. However, for this to = be useful, I believe that there are other boundaries that need to be = reported. I believe that in essence, all the boundaries need to = generate a CHECK CONDITION, as per the case for RED=3D2, as the = initiator will need to employ a different decompression algorithm upon = crossing each boundary.   
> 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. I would agree that this would be acceptable behavior = iff DDE=3D0. I would still prefer that each 'entity' be a single = logical block, but you may be able to convince me otherwise. At bare = minimum, the LBAs of blocks downstream of the 'entity' should not be = altered. > 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. We are in agreement on this. As I alluded above, my = original post did not properly consider the case of DDE=3D0. I believe = the behavior I originally posted, and that you mention in the paragraph = above, is the only appropriate behavior for the case of = DDE=3D1. I have yet to encounter a 'real world host' which = sets DDE=3D0. Typical 'hosts' trust the drive to get the = compression/decompression right. As such, they employ no unique error = handling for decompression errors, as opposed to generic permanent read = media errors. As such, my intent for the case of encountering = non-decompressible data, when DDE=3D1, is to allow the initiator to = employ the same error recovery/defect skipping algorithm as would be = employed in the presence of a permanent read media error. > 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? If DDE=3D1, the logical block that is at that = location should be returned to the initiator. In the general case, this = may require the 'physical' read operation to start at some point before = the desired LBA, in order for the decompression hardware to be able to = decompress an entire 'compression unit'. Note that this does not = preclude returning the precise logical block the initiator positioned = to. I would guess the proper thing in the case of DDE=3D0 = would be to return a CHECK CONDITION. This is due to the fact that it = is nonsensical to locate a logical boundary within compressed data. = (caveat below)   
> Can't give 
> the host part of the entity. I suppose there are some heroic iterative steps the = drive could invoke to map logal boundaries to some byte location within = the compressed data, but this still could not be employed for any = unsupported algorithm. > 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) Yes, it can be complex. However, at least in the case = of DDE=3D1, this has been a routine requirement for quite a = while. > 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. As I mentioned earlier, we do not claim support for = DDE=3D0. Similarly, we claim support for only RED=3D0. As such, our = defaults are different from yours. Your interpretation of DDE=3D0 = causing all algorithms to be treated as unsupported seems eminently = sensible to me. There seems to be a larger question, however. If a = drive does not support a given compression algorithm, how is it to = distinguish between an 'entity' encoded with that unsupported = algorithm, and data read with an uncorrectable read error? In our case, = if we can read a 'physical block' from the medium, (along with any = associated physical blocks that are part of the same 'compression = unit'), yet we are unable to decompress the data, there are exactly = three factors which could cause that error: The decompression hardware = is broken, in which case the proper thing to do is to not return that = data, but rather return CHECK CONDITION - Hardware Error, or; One or = more bits of the 'physical block' in our buffer have changed state = after reading them from the medium, with the same result as the = previous case (after internal retries fail), or; The 'physical block' = had a pathological pattern of bits in error which caused the error = detection portion of our ECC algorithm to let the error pass undetected = (a vanishingly small probability, but admittedly a mathematical = possibility), in which case the proper thing to do would be to not = return the data, but rather issue a CHECK CONDITION - Permanent Read = Error (after internal retries, of course). Note that in each of these = cases, it is nonsensical to return the data to the = initiator. Somehow, I cannot understand what possible use an = initiator might make of any data transferred to it, under the case of = DDE=3D0, RED=3D0, and a boundary is crossed from uncompressed to = compressed. If a CHECK CONDITION accompanied the data, then a = sophisticated inititator could presumably decompress the data itself. = However, if the data is returned without any indication that the data = is now in compressed form, it has no way of knowing that it needs to = process the new logical block with its own decompression. It seems to = me that this is certain to result in a failed restore operation, as the = data it is getting back is *not* the data it sent when = writing. > 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. Agreed. Neither did I. > 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 
> 
> 
> 
> 
------_=_NextPart_001_01C1C533.D47313C0--




More information about the T10 mailing list