I've been experimenting with some magnetic tapes recently, in prep. for a
chapter on usage for The Guide.  Basic tape operations are straight
forward (creating, updating, appending) and my docs are progressing, but
I'm curious about a few things and was hoping for some feedback.  Some of
the man pages havn't been touched in years, so I'm hoping to clear up some
issues.

First off I'm on port/sparc.  My drives are attached to isp0.  They are:

#1: This is a DDS2 drive.

st0 at scsibus1 target 0 lun 0: <ARCHIVE, Python 03812-XXX, 652B> SCSI2
1/sequential removable
st0: density code 140, 512-byte blocks, write-enabled

#2: This is a QIC drive (I think)

st1 at scsibus1 target 5 lun 0: <TANDBERG, SLR5, 0906> SCSI2 1/sequential
removable
st1: density code 160, 512-byte blocks, write-enabled


1) With my st0/DDS2 drive, why does the 'mt erase' command return
immediately to the prompt after execution if the command hasn't completed?
This presents scriping / automation problems, for example, if I run 'mt
erase', then immediately after that run 'mt status' or 'tar', I will get
an I/O error.

[Mon Mar 18 @ 01:46am] $ mt -f /dev/rst0 erase
[Mon Mar 18 @ 01:46am] $ mt -f /dev/rst0 status
mt: /dev/rst0: Input/output error

<---- wait until drive is silent ---->

[Mon Mar 18 @ 01:48am]$ mt -f /dev/rst0 status
SCSI tape drive, residual=0
ds=3<Mounted>
er=0
blocksize: 0 (0, 0, 0, 0)
density: 140 (0, 0, 0, 0)
current file number: 0
current block number: 0

More importantly, does 'mt status' during an 'mt erase' interrupt the
erase prematurely? It's hard to tell.

From a scripting standpoint, you could do a test on the retun code of 'mt
status' (0,1,-1) in a while loop, etc., but I'm curious as to why only the
DDS2 drive exhibits this behavior.

2) Is there a reliable way to estimate the maximum capacity of the drive
based on the length of the tape (aside from the advertised capacity on the
media)?

The obvious solution is some sort of formula based on drive density *
records.

For example, with both my drives, I tried "dd if=/dev/zero of=/dev/st0
obs=512".  The idea was to measure how many "records" out were written,
but this seems to cause problems with the tape (it "sounded" like the tape
got stuck writing records at the end).  The dd command never completes.

3) Based on #2, assuming you could accurately estimate the maximum
capacity a tape can hold (not including hardware or software compression),
would it be possible to create archives of multiple volumes (media) using
the gnu tar with the following options:

For example, in pkgsrc/archivers/rar, the format is:

$ rar a -m0 -v[vol size][k|b] [archive] [files]

In GNU tar, I see the folowing option:

     -L number
     --tape-length number    Change tapes after writing N*1024 bytes

So i guess the question in the formula to determine "N", which leads back
to #2

4) Does it make more sence to use tar(1) to pass through gzip(1) or
bzip2(1) to do compresstion, or use hardware built-in compression?  Just
looking for opinions speaking from an experience standpoint.


5) Does anyone have an ATAPI based tape drive?  Can you send me some dmesg
examples?  Are operations any different? (i know port/i386 tends to
associate atapi devices w/ scsibus0)