Minutes of SSC Meeting on 11/10

exabyte!smtplink!tedl at uunet.uu.net exabyte!smtplink!tedl at uunet.uu.net
Wed Nov 16 06:40:01 PST 1994


Minutes of SSC Working Group Meeting on 11/10/94             X3T10/94-241r0

To:     Membership of X3T10

From:   Edward Lappin
        Exabyte Corporation
        tedl at exabyte.com
        (303) 447-7718

Date:   November 15, 1994

Subject:  SSC Minutes of SSC/SMC Working Group Meeting of 11/10/94

A meeting was scheduled for Thursday 11/10/94 at 9:00 AM for
discussion on both the SSC (Stream) and SMC (Changer) command
sets.  This meeting covered issues on tape and medium changer
commands.

Attendees:
 Edward Lappin     Exabyte
 Erich Oetting     Storage Technology
 Neil Wanamaker    Amdahl
 Lansing Sloan     Lawrence Livermore Labs
 Bob Snively       Sun Micro
 Gary Stephens     FSI
 Bill Dallas       Digital
 Jan Dedek         Ancot
 Ralph Weber       Digital

We started by bringing up a list of topics to discuss for tape.
We came up with a variety of issues:

  Response of TUR during immediate commands
  Residue on space
  Read position
  Density Codes
  Partitions
  More specific text on ASC/Q
  Load Display
  Other tape commands
  Format
  Determining the density and blocking factors EOM setting
  R/W dammit
  Space past EOD

Bill argued for known blocking factors.  He wanted to know if the
tape is written with fixed or variable blocks and the block size.
Gary argued against this since this would change the model.  The
group generally agreed that this is not a function of the tape
device.  Instead, the application must determine the correct
blocking and how to determine the tape format.

Erich brought up the question of how Test Unit Ready should
respond while an immediate command is in progress.  Possible
responses include Busy, Good, Check Condition (not ready but
becoming ready), and disconnecting.  Erich pointed out that
disconnecting for a "long time" is not in the spirit of TUR.
Bill asked about unload immediate.  We diverged into talking
about read position and what it should report.

Other possible responses included a new ASC/Q for immediate
command in progress.  But, responding with a CHECK CONDITION may
break current implementations.  Also, it is reasonable for Read
Position to disconnect for the duration of the immediate command.
The possibility of progress indication was raised.  This would
use the sense-key specific part of the Request Sense data to
indicate the state of the immediate command.  Commands we thought
about for this discussion were Rewind, Verify, Erase, Locate,
Format, Load, and Unload.

Bill also pointed out that Read Position should be required to
allow multi-initiators to determine where the tape is located
when a new initiator accesses the drive.  He wants Read Position
to be mandatory. Gary pointed out that if the BIS bit in page 10h
of the mode data is set, then Read Position should be supported.
I agreed and noted that a device can report BPU if the block
position is unknown.

We agreed that Read Position should be mandatory.

Erich asked that two bits be added to the short Read Position
data, to indicate that the number of blocks in the buffer and the
number of bytes in the buffer are respectively invalid.   I
agreed to write up a proposal adding these bits.

Getting back to TUR, Gary asked that it be stated in the model
(explicitly) that the logical unit is ready if the tape is
mounted.  After more discussion, the rules seem to boil down to
the following:

 1.  If the volume is being mounted or unmounted, the device
     shall return CHECK CONDITION to a TUR command, with an
     appropriate status (depends if unloading or loading).
   
 2.  If the volume is mounted, the device shall return GOOD
     STATUS in response  to a TUR.
   
 3.  If the volume is not mounted, the device shall return NOT
     READY  in response to a TUR.
   
[The ASC/Q are set to appropriate values when CHECK CONDITION is
returned].

For Read Position, the BPU (and MPU) bits are set when the
immediate command is in process.

Additionally, a request sense during an immediate command shall
return a Sense Key of 0 (No Sense) with an ASC/Q of 00, 16
indicating IMMEDIATE COMMAND IN PROGRESS when no other sense is
available.  The Sense Key specific data, if present, indicates
the progress of the immediate command (as a fraction of 65536, as
specified in the Request Sense Command description).

I will write up a proposal on the required ASC/Q.

We discussed space and the residual on a backwards space and it
was unanimously agreed that the residual shall be greater than or
equal to 0.

I will clarify in SSC that a failed locate command does not
guarantee the position (this is also true of a failed partition
change).

We talked about density codes.  I noted that we are using up the
density codes (there were 21 in SCSI-2 and there are about 45
now).  We have space for 126.  The thought was we should use the
format and compression algorithm to differentiate formats.
However, this has a drawback in that many initiators use the
density code to select but not the format.  I stated that we
should consider using Vendor Unique (ugh) density codes as
required to allow initiators to select different formats.

Also, we were thinking that page 10h of the mode data should be
mandatory.  However, we need to think about this since we
couldn't quite agree on this issue.

Erich asked about Load Display.  Currently, tape devices with
displays use a vendor-unique command to load the display.  Gary
and I pointed out that this may not be practical since the
display has characteristics which really require a model.  This
degenerated into the idea that we need a new command set.  The
result was we will leave it vendor unique.

I will add the format medium command (94-146R3) to SSC.

For partitions, Gary wants more of them.  He is going to write a
proposal for adding more partitions.  This may require a new
command and modifying the Locate command.  Meanwhile, I will work
on the wording of 94-152R0 (partitions). Gary pointed out I need
to change some text in the density code section.  We agreed and I
will also be enhancing the text.

Bill still wants block information (blocking factor for the
device).  He is concerned about the lack of labels for tape data.
However, the rest of us think that this is a defect in the tape
data definition for the applications, not SCSI.  Erich and I
argue that fixed and variable blocks are not differentiated by
the device and the tape does not contain the blocking factor
information at the start of the tape (the block size can change
at any time for most tape drives).  Bill pointed out that QIC
drives may not support a range of block sizes.  Gary pointed out
that only supporting some block sizes and reporting the range in
Read Block Limits is in violation of the model.   The rest of us
agreed with Gary.

We agreed that EOM should only occur if we are past Early Warning
or if an action causes the end of the tape to be hit (ie,
positioning to block 0 by spacing back only causes EOM if the
space residual is greater than 0).  A successful space back to 0
should never generate EOM.

Bill brought up Read and Write Dammit.  This is a mode where the
drive does not report errors on read or write and gives the
initiator whatever data it has.  We also diverged into reading
past EOD (the case when the user accidentally writes at the front
of the tape and wants to recover gigabytes past the new data).

[Note:  we need a better name for R/W Dammit]

All of this resulted in the idea we should have bits in Read and
Write to set this special data mode (but not in verify).  I will
write a proposal.

Additionally, a new space mode, namely space from EOD to the next
data, will be added.  I will also write up a proposal.  Note that
we will not space from EOD to data if we are not at EOD and this
will result in an ILLEGAL REQUEST.  This will be an optional
mode.

Gary asked if a 10 byte read is required?  The rest of us think
not.

Finally, we got to SMC. See the SMC working group report for a
summary of the SMC issues and decisions.

We adjourned at 12:40.  We will meet for both SSC and SMC again
in January.




More information about the T10 mailing list