SCSI Tapes and Fibre Channel

[Bill Dallas]

* From the SCSI Reflector, posted by:
* Bill Dallas  <dallas at zk3.dec.com>
*
Erich,

You will find my comments the body of your response.

Thanks,
Bill

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

I believe that the queuing model as defined today does preserve ordering.
We could go into a large rathole on this one.  I beleive the SCSI-2
spec. does state the device must maintain ordering in a number of 
fashions but not directly.

The handling of queued items is no different then the write buffer model
today.  If the host wants to signal the user of an error on the request
that failed then it must create a list of requests that is currently
in the tape unit but not on the media.  

The idea of a request sense for each command that fails in the queue
after the first fails is not necessary, we are only interested in the 
command that first failed.  The queue error bit will abort the queue,
for a nice cleanup.

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

I disagree that knowing the exact record that failed is irrelavent.  If
I have 10 gig of data written on a tape and get an write error an
application must know which record exactly failed so that the tape can
be cleanly closed, dismounted and procede to the next tape where it left
off.  You just don't throw that 10 gig of data away.

Yes using the recovered buffer data command can be used but with tagged
commands you don't need it.  The use of the Recover Buffered Data 
command just adds complexity to the drivers where simplicity is the key.

>From the software developers to the device manufactures everyone
wants the implement the KISS principal.  If everyone did KISS then
nothing would work.  There must be even tradeoffs,  


>
>  ... Erich Oetting
>
>
>
>