SCSI Tapes and Fibre Channel

[Erich Oetting]

* From the SCSI Reflector, posted by:
* erich_oetting at stortek.com (Erich Oetting)
*
>* From the SCSI Reflector, posted by:
>* dallas at zk3.dec.com
>*
>
>I have been following the SCSI tape discussion and have decided to
>jump in with my 2 cents.  I have not included all the other postings
>in this response since everyone that has been following this thread
>knows what has transpired.
>
>First I would like to comment on changing the tape model to accommodate
>the lack of functionality that FCP presents for SCSI devices other then
>disks.  Why are we hacking and whacking the the device models to shoehorn
>device types other then disk onto the FCP SCSI mappings?  First we hack
>the tape model but there are other device models that need to change to
>accommodate FCP (e.g., worms, cd-rs, printers, etc.).
>
>Changing the device models for FCP requires the host software to support
>X number of models. Do we change the models across the board for all the
>SCSI channels so that the host software only needs to support one model
>or does the host has to support the one model for FCP and one model for
>all the rest of the SCSI mappings?
>
>Now onto the tape discussion.  Doug's proposal for the large buffer tape
>model only increases the costs of the tape drives by requiring large
>amounts of memory in the drives.  The proposal requires the software vendors
>to change the drivers and applications for the new special tape model and
>support the old models. The proposal is a point solution and addresses only
>tapes and is not a generic solution for other device models and functionality.
>If the tape vendors care about the costs or disagree they can enter
>into this discussion with their 2 cents.
>
>Write buffering for tapes is archaic and as Rod Van Meter pointed out
>presents a number of problems for the host software.  Write Buffering
>was developed in SCSI-1 to keep the drives streaming (before SCSI-2 Tags).
>Write buffering has outlived it usefulness and tag command queueing for
>tapes is just starting to come onto the market. It is about time that
>tapes are starting implement tagged commands but the FCP limitations
>will keep tape implementions in the dark ages for years to come.

Using tagged command queueing with tape drives is certainly possible, but
I would not be so fast in dismissing the current buffered model.  The
sequential nature of tape data requires preservation of command order,
something not guaranteed by the present queueing model.  Host vendors
also need to consider the problems in handling thousands of queue items.
(Large helical scan drives may collect over a thousand write records
before even starting to move tape.)  Also, when a write command fails
all subsequent write commands in the queue will fail, requiring to host
to handle autosense data for each.

The current buffer model fits well with the nature of tape errors.
Tape write errors that are not handled internally by the drive generally
preclude writing to the rest of the tape.  Really catastrophic errors, such
as tape breaking, may preclude reading data previously written succesfully.
Because of this, most tape applications do not consider a write successful
until the file is closed and the buffer syncronized, or more conservatively
when the tape is unloaded.  Knowing the exact write record that failed is
irrelavent if recovery is done at the file or tape level.  Attempting to
recover to the record level is possible using the Recover Buffered Data
command.

  ... Erich Oetting