In regard to: Re: [Networker] Need help with stinit.def for LTO-3, George...:
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?
That could just be a difference between our field service engineers and
yours. Our FSEs and pre-sales support said we could use any of the
available vendors, but they recommended HP because they had seen much
higher times between failures with those.
I honestly wouldn't worry about it. I'm sure the IBM drives will be fine.
# 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.
No matter which vendor you choose, the SCSI protocol support and drive
behavior should be extremely similar, so an stinit.def for one vendor's
drive should be a good starting point when working with a different
vendor's LTO drive -- I would just start by changing the manufacturer
and model strings.
As far as scsi2logical=1 (use logical block addresses rather than
device-specific addresses), I'm not sure. When I asked Legato about
stinit.def entries for our SuperDLT1 drives years ago, their support
pointed me at this
http://www.nclug.org/pipermail/nclug/2002-August/004162.html
which has scsi2logical=1 set for all the DLT type drives. I've also seen
scsi2logical=1 set for other types of drives. That doesn't mean that LTO
should have it set to 1, but I've definitely seen more stinit.def entries
that have it set than those that don't. Since the example I received
from STK/Sun had scsi2logical listed (which means scsi2logical=1), it
matched my previous experience with most tape drives.
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',
It is (assuming buffer-writes is even valid!).
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
It probably is the same, since stinit uses the shortest distinct substring
to determine what the actual keyword is. You could probably use
buff-the-floor=1
and still get buffering. I haven't actually tried that.
Note that I'm surprised that Quantum suggests buffering=0. I would
think that would hurt performance.
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?
I'm operating under the assumption that LTO drives from different
vendors should be very very similar WRT these settings. I think Quantum
is setting buffering=0 because it's the more conservative setting. Ditto
for async-writes=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'.
Those are more conservative settings than what we're using. I'm guessing
that you're taking a performance hit for writes, but it might be pretty
small.
NetWorker goes to great lengths to correctly handle tape transitions,
and AFAIK using the more "dangerous" settings has never bitten us. We've
been using NetWorker for approximately 11 years with about the last five
of those being on a Linux server, so I would think we would have seen
problems by now if the config settings we were using were problematic.
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
buffering is probably the same as buffer-writes, the other two look like
reasonable settings.
Not sure what the default is for keywords not overtly defined in stinit.def?
That probably depends on the st module.
# 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
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?
Perhaps, but I always thought that those modes only mattered for
writing, and since LTO3 cannot write in LTO1 format, there's no point
defining a mode for it.
You have the uncommonly good luck of being in a position to test it
and report back, though, since you have LTO1! ;-) All you have to do
is take one of your LTO1 tapes, load it in one of your LTO3
drives, and then read it using one of the device files that is not
configured for LTO1. If you can read it, you've proved that the modes
don't matter for the read case.
You can either try running scanner on an LTO1 tape (use the -n -i options,
to scan the tape but not modify your indexes) or you can just scarf the
label off the tape:
dd if=/dev/nst0 of=/tmp/tape-label bs=128k
You will need to match the setting for blocksize (bs) to whatever you were
using to write to the LTO1 tapes with your older drives. That should
give you a file in /tmp with the contents of the NetWorker tape label in
it, you can get a view of the format using
od -t c /tmp/tape-label | less
If that works, you'll have proved that you don't need special settings
for reading a tape written in an older (but compatible) format.
Maybe I can track down a similar book for the IBM drives, but my guess
is that the density codes will be the same.
I'm sure they will be.
Tim
--
Tim Mooney Tim.Mooney AT ndsu DOT edu
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
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
| 