Medium Partition and Data compression pages

[DOUG.PIRIE at conner.com]

* From the SCSI Reflector, posted by:
* DOUG.PIRIE at conner.com
*
Jorgen Johanson writes:

>* From the SCSI Reflector, posted by:
>* JOJO <jojo at cc2smtp.tdata.no>

>Hallo,
>     
> We have some questions regarding medium partitions and data compresssion. 
> We are looking at a sequential access device (like a tape streamer). In 
> this case the medium is typically removable. It is also typical that the 
> device is able to operate on medias of diffent types. The different medium 
> types have different capabilities (like different capacities, varying 
> possibilites of storing information other then the bare data etc.)
> 
> 
> Medium Partition Page
> ---------------------
> We have a question regarding the Medium Partition Page(1) specified in 
> X3T10/997D rev.5 page 54 (section 5.3.3.3).
> 
> The description of the "Maximum Additional Partitions" field indicates that 
> the value of this field is "a logical unit-defined value indicating the 
> maximum number of additional partitions supported by the LOGICAL UNIT".
> 
> In our case however, the maximum number of partitions is determined by the 
> type of the MEDIUM currently inserted into device (a QIC-1000 type medium 
> allows a maximum of 2 partitions while a QIC-5010 type medium allows 36 
> partitions). In some ways this is also more logical in that the both the 
> actual total capacity and the how the total capacity is structured (into 
> partitions) are both typically determined by the medium and not by the 
> device (partitioning is a medium attribute).
> 
> 1) Should not the "Maximum Additional Partitions" field be a medium 
> type-defined value (and not a logical unit-defined value)? As it is now it 
> is not possible to determine the maximum number of partitions allowed by 
> the medium?
> 
> 
> Data Compression Page
> --------------------- 
> We have two questions regarding the Mode Select Data Compression Page 
> specified in X3T10/997D rev.5 page 48 (section 5.3.3.1).
> 
> In our case we have some medium types that do not have the possebility 
> of indicating that the data on the medium have been compressed (and 
> because of this there is no indication of the compression algorthm 
> used).
> 
> 2) When such a medium is inserted into the device, what should a Mode 
> Sense command report in the Data Compression Page?
> 
> Since there may be possible problems related to using compression on 
> such mediums (like reading back data without knowing if it has been 
> compressed or not), we would like to dissallow using compression 
> altogether on these media types.
> 
> 3) How should a device indicate that compression is currently not 
> allowed?
> 
> We have three suggestions, we but are not sure which one is 
> appropriate:
> 
>   A)  The Data Compression Capable (DCC) field may be used. However, 
>   ANSI defines this field as a "non-changable" field. The field is 
>   related to the device and not to the currently inserted medium.
> 
>   B)  The Data Compression Enable (DCE) field may be used and a Mode 
>   Select with this bit set can give Check Condition when the currently 
>   inserted medium has a type that we do not want to use for compressed 
>   data. However, DCE may be enabled BEFORE the medium is inserted 
>   (before we know the medium type).
> 
>   C)  The Decompression Algorithm field may be used. If the inserted 
>   medium is not blank, the host may give a READ 1 block command and 
>   issue a Mode Sense to get the Decompression Algorithm. A 
>   Decompression Algorithm of zero indicates no compression (the medium 
>   type is such that compression is not allowed). If the inserted tape 
>   is blank, a single dummy block may be written (DCE=1) and read again. 
>   As above, the Decompression Algorithm may indicate if compression was 
>   used (that is if was allowed by the device or not).
> 
> 
> Bjarte Myrold via
> 
> =========================================================================
> Jorgen Johanson            jojo at tdata.no
> TANDBERG DATA STORAGE AS
> P.O Box 134 Kjelsas
> N-0411 Oslo, NORWAY
>

Medium Partiton page
--------------------
While the capacity and number of partitions may be determined by the medium 
type and data format type for QIC drives it is not true for all tape devices. 
DAT drives in particular will physically format the tape based on values 
supplied by the host in the Medium Partition page.  In this case it is not 
the medium type which determines the number or size of the partitions and 
therefore partitioning is not a medium attribute.
I am not sure what you mean by the sentence," As it is now it is not possible 
to determine the maximum number of partitions allowed by the medium?" If the 
QIC-5010 spec. is similar to other QIC specs. then the number of and size of 
partitions is fixed and unalterable by the host. If this is the case, then 
maybe you know the max. number of partitions because you have read the data 
format type on the tape.  

Data Compression Page
---------------------
The answer to this problem is to not allow a Mode Select complete 
successfully until the drive is ready.  This forces the host to wait until 
you have read the tape before a Mode Sense has 'real' data.  I think a Mode 
Select should return Not Ready or Illegal Request when a drive is 
initializing a tape.  Your customers shouldn't have a problem with this, they 
can't use the drive until it is ready anyway.  Another option would be to 
disconnect when the Mode Sense cdb is issued and don't return until the tape 
is read.
I think it is perfectly acceptable to set the DCC field to one and the DCE 
field to zero.  The DCC field relates to the logical unit, as it should, and 
the DCE field relates to the data to be written.  Again, don't allow the host 
to set any fields before you have read the tape.
I disagree with your interpretation of what a Decompression Algorithm value 
of zero means.  If the value is zero after you read a block then you read 
uncompressed data.  It does not mean that compression is not allowed.  In the 
QIC formats that I am aware of compressed data is written into a 'Compression 
Block Group'.  A Compression Header will identify the QIC compression 
algorithm, and whether or not the data in the group is compressed or 
uncompresed.  If you read a block and the data is formatted into compression 
group blocks you still could have uncompressed data and have a value of zero 
in the Decompression Algorithm field.  Again, as long you don't let the host 
complete a Mode Select cdb before you are ready ( or hold off on Mode Sense ) 
you shouldn't have any problems.  Writing a block to tape isn't worth the 
effort.  How is the host going to know what you support without issuing 
another Mode Sense anyway?

By the way, if you are making this a SCSI-3 compatible drive you need to look 
at the Report Density Support command which will be mandatory.

Note to SSC group: Do we need to add field(s) for compression information?