1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
.\" $OpenBSD: st.4,v 1.15 2003/06/06 10:29:42 jmc Exp $
.\"
.\" Copyright (c) 1990, 1991, 1993
.\" The Regents of the University of California. All rights reserved.
.\"
.\" This code is derived from software contributed to Berkeley by
.\" the Systems Programming Group of the University of Utah Computer
.\" Science Department.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" from: @(#)st.4 8.2 (Berkeley) 11/30/93
.\"
.Dd November 30, 1993
.Dt ST 4 hp300
.Os
.Sh NAME
.Nm st
.Nd
.Tn CCS SCSI
tape driver
.Sh SYNOPSIS
.Cd "st* at oscsi? target ? lun ?"
.Sh DESCRIPTION
The
.Nm
driver was written especially to support the Exabyte
.Tn EXB-8200 8MM
Cartridge
Tape Subsystem.
It has several extensions specific to the Exabyte, but should support other
tape drives as long as they follow the
.Tn ANSI SCSI-I
specification.
Besides extensive use with an Exabyte, the driver has been tested with an
Archive
.Tn QIC-24
tape drive.
The
.Nm
tape interface provides a standard tape drive interface
as described in
.Xr mtio 4
with the following exceptions:
.Bl -enum
.It
Density is dependent on device type.
Current Exabyte hardware has only one density.
The
.Tn EXB-8500
drive, when released, will have a high
density format of
.Tn 5.6GB .
On an Archive
.Tn QIC-24
drive the driver reads both
.Tn QIC-11
and
.Tn QIC-24
formats
but writes only
.Tn QIC-24 .
.It
Only the ``raw'' interface is supported.
.El
.Pp
Special Exabyte Support:
.Pp
The
.Dv MTIOCGET
.Xr ioctl 2
call on an Exabyte returns this structure:
.Bd -literal
struct mtget {
short mt_type; /* type of magtape device */
short mt_dsreg; /* sc_flags */
short mt_erreg; /* high 8 bytes error status */
/* low 8 bytes percentage of Rewrites
if writing, ECC errors if reading */
short mt_resid; /* Mbyte until end of tape */
};
.Ed
.Pp
Bit 4 in the minor device number is used
to select long filemarks or short filemarks.
A long filemark occupies 2.12 MBytes of space on the tape, while a short
filemark occupies 488 KBytes.
A long filemark includes an erase gap while the short filemark does not.
The tape can be positioned on the
.Tn BOT
side of a long filemark allowing
data to be appended with a write operation.
Since the short filemark does not contain an erase gap which would allow
writing it is considered to be non-erasable.
If either type of filemark is followed by blank tape, data may be appended
on its
.Tn EOT
side.
.Pp
Bit 5 in the minor device number selects fixed block mode with a block
size of 1K.
Variable length records are the default if bit 5 is not set.
.Pp
For unit 0 here are the effects of minor device bits 2,3,4,5.
For other units add the
.Em unit#
to each of the device names.
.Bl -column norewind density filemarks -offset indent
.Em norewind high short fixed
.Em density filemarks block mode
rst0
nrst0 X
rst8 X
nrst8 X X
rst16 X
nrst16 X X
rst24 X X
nrst24 X X X
rst32 X
nrst32 X X
rst40 X X
nrst40 X X X
rst48 X X
nrst48 X X X
rst56 X X X
nrst56 X X X X
.El
.Sh SEE ALSO
.Xr mt 1 ,
.Xr \&ct 4 ,
.Xr hd 4 ,
.Xr intro 4 ,
.Xr mtio 4 ,
.Xr oscsi 4 ,
.Xr sd 4
.Rs
.%T EXB-8200 8MM Cartridge Tape Subsystem Interface User Manual
.Re
.Sh BUGS
The
.Tn HP
98268
.Tn SCSI
controller hardware can not do odd length
.Tn DMA
transfers.
If odd length
.Tn DMA I/O
is requested the driver will use the
"Program Transfer Mode" of the Fujitsu
.Tn MB87030
chip.
Read requests are normally even length for which a
.Tn DMA
transfer is used.
If, however, the driver detects that an odd length read has happened
(when an even length was requested) it will issue the
.Dv EIO
error and the last byte of the read
data will be 0x00.
Odd length read requests must match the size of the requested data block
on tape.
.Pp
The following only applies when using long filemarks.
Short filemarks can not be overwritten.
.Bd -filled -offset 4n
Due to the helical scan and the erase mechanism, there is a writing
limitation on Exabyte drives.
.Dq Li tar r
or
.Dq Li tar u
will not work
.Pf ( Dq Li tar c
is ok).
One can only start writing at 1) beginning of tape, 2) on the
end of what was last written, 3) "front" side of a regular (long) filemark.
For example, you have a tape with 3 tar files.
If you want to save the first file, but overwrite the second two files with
new data, on a normal
1/4" or 1/2" drive you would do:
.Pp
.Li "mt fsf 1; tar cf /dev/nrst0 ..."
.Pp
but for an Exabyte you need to do:
.Pp
.Li "mt fsf 1; mt bsf 1; mt weof 1; tar cf /dev/nrst0 ..."
.Pp
The regular long filemark consists of an erased zone 3.8" long
(needed to begin a write).
In this case, the first filemark is rewritten in place, which creates an
erased zone
.Em after
it, clearing the
way to write more on the tape.
The erase head is not helical.
.Pp
One can position a tape to the end of what was last written by reading
until a
.Tn \*qBLANK CHECK\*q
error is returned.
Writing can be started at this point.
(This applies to both long and short filemarks.)
The tape does not become positioned somewhere down the "erased" area as
does a conventional magtape.
One can issue multiple reads at the
.Tn \*qBLANK CHECK\*q
error, but the Exabyte stays positioned at the beginning of the
blank area, ready to accept write commands.
File skip operations do not stop at blank tape and will run into old data
or run to the end of the tape, so you have to be careful not to
.Dq Li mt fsf too_many .
.Ed
.Pp
Archive support gets confused if asked to move more filemarks than there are
on the tape.
.Pp
This man page needs some work.
Some of these are not really bugs, just unavoidable consequences of the
hardware.
|
