SCSI Tapes and Fibre Channel

dallas at dallas at
Wed Jul 10 09:15:52 PDT 1996

* From the SCSI Reflector, posted by:
* dallas at

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. 

Rod asked a number of questions that I will try to answer.

>* Is it true that an error from the tape drive means the cartridge is
> essentially unusable? What about VOLUME OVERFLOW (rare due to extra
> room past EOT, but on write retries with lots of write caching and
> long records, could happen)? What about RECOVERED ERRORs that the
> system might want info about (e.g. to decide to make a second copy, if
> error rate was high)?

For some types of tape drives there are some recovery options for MEDIA errors
reported by the unit.  The VOLUME OVERFLOW error is not really all that
important (extremely rare event) the real worry is early warning end of media.
This is where most of the deferred error handling comes into play.  Figuring
out what has been writing to media, what user request (write cmd) to signal
that an EWEOM has been detected so that they can close out this tape and
continue to the next.  I don't think many drivers would would want to make
secondary copies of data to media (data interchange reasons), it is up 
to the application to make those decisions.  I think the bigger question is
RECOVERED ERROR deferred with a 0 in the info bytes vs RECOVERED ERROR 
deferred with a positive value in the info bytes.

>* What do current systems do about tape errors? tar obviously handles
> it poorly; VMS BACKUP, better. What about HSM packages and automated
> backups? How do they deal with the perhaps gigabytes of good data on
> the tape?

Some application variants of the same tape format (tar) handle errors 
better then others for writes by logically closing the tape and going 
to a new one other apps just die.  Reads are a bit more complicated
based one the tape drive and the application.  If we take tar for an
example the app. may report the error saying it can not retrieve the
file and skip to the next, but the tape drive may not allow the app. 
to skip over the bad record (reports media error for operations that
require the tape to read the media (read, space, etc.).  I can't answer
the HSM question.

> * Especially, how do current systems deal with deferred errors?  Tape
> drives support nothing like SYNCHRONIZE CACHE (at least not in
> SCSI-2); how do systems know the data is safe?

If a system handles deferred errors it is with extreme difficulty, a ton of
code and memory usage.  The write write write(deferred error) case is 
just one of the conditions, there is write, write, 
write file marks(deferred error) and write, write, space(deferred error, 
and write, write, rewind(deferred error) and the list goes on. As Rod 
noted if you handle deferred errors correctly in the driver you must 
maintain a list of current commands (commands to unit but not on media) 
so that you can correctly indicate back application which request failed.
That either requires guess work on which request made it to the media
so that you can indicate back to the app correct status.  You can also
take the guess work out by slipping in a write filemark count 0 command
into the stream every X number of commands to flush the cache but 
performance then suffers.
The write filemark command with a count of 0 (don't write any) will flush
the buffered data to media.

> * What is the true performance impact of the "large buffer" model with
> write caching and deferred errors (LBWCDE)?  Perhaps it's so small as
> to be a non-problem.

I just do not know, but in a fabric with large enought command flight 
times I think performance will suffer.


More information about the T10 mailing list