Thanks, Tim. I've inserted my replies below, along with several
questions that I'm
very puzzled about.
Tim Mooney wrote:
In regard to: [Networker] Need help with stinit.def for LTO-3, George...:
IBM told me that they cannot transfer me to tech support because we
do not have a current maintenance
contract with IBM, so no help. Storagetek told me they can't really
help with Linux, only Solaris (guess they're part of Sun now).
They also said that you really don't need stinit.def anymore.
I don't know if it's needed or not, but our StorageTek people worked
diligently to get help with the stinit.def for our library.
I can only hope that they will work diligently with us, too, but trying
to get Linux help seemed difficult.
Here's ours, for HP drives (which is what StorageTek strongly recommended
to us). They couldn't give us any suggestions for the mode/density
That's interesting because they shipped us IBM drives. We never
requested any specific manufacturer.
I find it surprising that they would use IBM drives, though, if HP was
recommended?
settings beyond the default, but they did provide the PDFs for the SCSI
capabilities of the drives themselves, so I wrote the mode/density
settings based on them. What you see below is therefore a hybrid of what
they recommended and the blanks that we filled in.
Well, I searched around and found some IBM documents. One of them has a
section on Linux and
even says that the Linux driver (kernel) is perfectly fine, and the IBM
driver, for example, is not required,
but nowhere in any of the documents does it mention anything about
stinit.def or what values to
put in there. I realize our drives are IBM and yours are HP, but since I
could not find anything specific
for IBM, I cross checked the stinit.def file that Quantum has (PDF),
which includes definitions for the various
Quantum SDLT and Certance LTO drives, against your values, just for
grins, and I have some questions below.
# LTO Generation 3
#
# TVM: here's what Sun/STK recommended:
#
# manufacturer=HP model="Ultrium 3-SCSI" {
# can-bsr scsi2logical drive-buffering auto-lock
# timeout=800
# long-timeout=14400
# mode=1
# blocksize=0
# density=0x00
# fast-eom=1
# }
manufacturer="HP" model = "Ultrium 3-SCSI" {
scsi2logical=1
can-bsr=1
auto-lock=0
two-fms=0
drive-buffering=1
buffer-writes
read-ahead=1
async-writes=1
can-partitions=0
fast-eom=1
1. I see that you have scsi2logical set to 1. I realize that this is for
HP LTO-3, but
Quantum's sample stinit.def file (in their PDF document) has this value
remarked out as:
#scsi2logical=1. Their stinit.def file includes definitions for all the
SDLT and various
LTO devices. Nowhere else do they have scsi2logical set. Does this sound
surprising?
2. I see you have 'buffer-writes', which I assume is equivalent to
'buffer-writes=1', but I
don't see a 'buffer-writes' keyword in the man page for stinit, but I do see
one called 'buffering', and I see "MT_ST_BUFFER_WRITES (Default: true)"
under the
man page for st. Maybe that's the same thing? The Quantum stinit.def
file has: buffering=0
4. You have 'async-writes=1'. Again, they have: 'async-writes=0'. Does
that make
sense? Would it make sense that maybe for HP LTO it might be set to 1,
but maybe,
say for Quantum SDLT and LTO, it's set to 0?
The drivers/scsi/README.st file in the Linux kernel source tree says:
"Asynchronous writing. Writing the buffer contents to the tape is
started and the write call returns immediately. The status is checked
at the next tape operation. Applies only to variable block mode.
Buffered writes and asynchronous writes may in some rare cases cause
problems in multivolume operations if there is not enough space on the
tape after the early-warning mark to flush the driver buffer."
The man page for st also says this:
MT_ST_BUFFER_WRITES (Default: true)
Buffer all write operations in fixed block
mode. If
this option is false and the drive uses a fixed
block
size, then all write operations must be for a
multiple
of the block size. This option must be set
false to
write reliable multi-volume archives.
MT_ST_ASYNC_WRITES (Default: true)
When this options is true write operations return
imme-
diately without waiting for the data to be
transferred
to the drive if the data fits into the driver's
buffer.
The write threshold determines how full the
buffer must
be before a new SCSI write command is
issued. Any
errors reported by the drive will be held until
the next
operation. This option must be set false to write
reli-
able multi-volume archives.
Since NetWorker does span tapes, is that what they mean by multi-volume
archives? So
does this sound like we need to set both buffer_writes=0 and
async-writes=0? As far as I know,
I've not seen any problems spanning volumes on our SDLT600 drives, and
we have
'buffering=0' and 'async-writes=0' but no keyword for 'buffer-writes'.
The other keywords and values that you have are all the same as those in
Quantum's stinit.def file,
but they also have these:
no-wait=0
buffering=0
noblklimits=0
Not sure what the default is for keywords not overtly defined in stinit.def?
Also, their definition for the LTO-3 drive looks like this:
# CERTANCE ULTRIUM
manufacturer=CERTANCE model="ULTRIUM 3" {
timeout=800
long-timeout=14400
can-partitions=0
mode 1 blocksize=0 density=0x44 compression=1 # ULTRIUM 3 density,
compression on
mode 2 blocksize=0 density=0x44 compression=0 # ULTRIUM 3 density,
compression off
mode 3 blocksize=0 density=0x42 compression=1 # ULTRIUM 2 density,
compression on
mode 4 blocksize=0 density=0x40 compression=0 # ULTRIUM density,
compression on
Very similar to yours, but they don't use a compression 'off' line for
LTO-2 like you have,
and they include a line for LTO-1. We, too, have never used LTO-2, only
LTO-1, but I
thought that even though we can't write to the LTO-1 media in LTO-3
drives that we would
still have to define a mode for it to be able to read properly?
The SDLT600 section likewise includes a mode4 for SDLT220 with
compression on, and
we can't write to our older SDLT 220 media in the SDLT600 drives since
it's read only, but since
they include it as one of the modes, I guess I thought we needed it.
#
# If your stinit supports the timeouts:
timeout=3600 # 1 hour
long-timeout=14400 # 4 hours
# 400 GB + compression
mode1 blocksize=0 density=0x44 compression=1
# 400 GB, no compression
mode2 blocksize=0 density=0x44 compression=0
# LTO2 ~= 220 GB + compression
mode3 blocksize=0 density=0x42 compression=1
# LTO2 ~= 220 GB, no compression
mode4 blocksize=0 density=0x42 compression=0
}
# end of LTO-3
We've been using this for more than a year, with good results. We
haven't, however, ever tried the LTO2 write compatibility, since we
never had LTO2 on site and have never tried to write LTO2. Note that
density code 0x40 (LTO1) is also supported *for reading*, but not
writing,
so there's no point defining it as one of the modes.
Note that I got the density settings from the "HP Ultrium tape drives
Technical reference manual Generation 3 drives", part # Q1530-90901
Volume
3, Edition 6, December 2004. The supported density settings can be found
in the description of the SCSI "REPORT DENSITY SUPPORT" command.
Maybe I can track down a similar book for the IBM drives, but my guess
is that
the density codes will be the same.
Tim
--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145 | Voice: (301) 713-3284 x210
1315 East West Highway | Fax: (301) 713-3301
Silver Spring, MD 20910-3282 | Web Site: http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
