After reading the man page for stinit more carefully, it does state that
the mode for the stinit.def
file must be 1-4, so apparently, even though the stinit program itself,
when run as stinit -v -v,
still reports the modes as 0-3":
stinit, processing tape 0
Mode 0, name '/dev/nst0'
Mode 1, name '/dev/nst0l'
Mode 2, name '/dev/nst0m'
Mode 3, name '/dev/nst0a'
The manufacturer is 'QUANTUM', product is 'SDLT600', and revision '2929'.
Mode 1 definition: timeout=3600 long-timeout=14400 can-partitions=0
blocksize=0 density=0x4A compression=1
Mode 2 definition: timeout=3600 long-timeout=14400 can-partitions=0
blocksize=0 density=0x4A compression=0
Mode 3 definition: timeout=3600 long-timeout=14400 can-partitions=0
blocksize=0 density=0x49 compression=1
Mode 4 definition: timeout=3600 long-timeout=14400 can-partitions=0
blocksize=0 density=0x48 compression=1
it must be associating Mode 0 with the Mode 1 definition, and mode 1
with the Mode 2 definition ... and Mode 3 with
the Mode 4 definition.
I assume that since the SDLT600 drives are backward read compatible with
SDLT 1 media that was labeled on a
320 or 220 drive, that if you put one of those tapes in there, and your
NetWorker devices are set to /dev/nst#, then
the Mode 1 definition will still be used. Seems to make sense since it's
the same drive. However, if you wanted for
some reason to use no-compression then you'd have to specify /dev/nst#l.
Or if you wanted to somehow use the drive
in 320 or 220 mode then you would specify /dev/nst#m or nst#a, I guess?
Our stinit.def file has one section for SDLT600 and another for SDLT220,
but seems to me that the 220 section
isn't getting processed or utilized since we don't have any 220 drives
in the library. /proc/scsi/scsi only reports the
600 drives, and I would think stinit will only see that info so its
ability to work with the SDLT 1 tapes must not be based
on the entries from the 220 section, but instead only what's listed for
the 600 section? In that case, since we're using
/dev/nst# (or mode 1) then it will be assigned a density of 0x4a. But if
we did have 220 drives, stinit would pick up the
information under the 220 section, and it would get assigned a code of
0x48 - still for mode 1. I'm thinking we
don't need the 220 section in /etc/stinit.def at all, but it's not
hurting anything to be in there?
# QUANTUM SDLT600
manufacturer=QUANTUM model="SDLT600" {
timeout=3600 # 1 hour timeout
long-timeout=14400 # 4 hour long timeout
can-partitions=0
mode1 blocksize=0 density=0x4A compression=1 # SDLT600 density,
compression on
mode2 blocksize=0 density=0x4A compression=0 # SDLT600 density,
compression off
mode3 blocksize=0 density=0x49 compression=1 # SDLT320 density,
compression on
mode4 blocksize=0 density=0x48 compression=1 # SDLT220 density,
compression on
}
# QUANTUM SDLT220
manufacturer=QUANTUM model="SuperDLT1" {
timeout=3600
long-timeout=14400
can-partitions=0
mode1 blocksize=0 density=0x48 compression=1 # SDLT220 density,
compression on
mode2 blocksize=0 density=0x48 compression=0 # SDLT220 density,
compression off
mode3 blocksize=0 density=0x41 compression=1 # DLT8000 density,
compression on
mode4 blocksize=0 density=0x41 compression=0 # DLT8000 density,
compression off
}
Darren Dunham wrote:
Quantum M1800 tape library with
four SDLT 600 drives, attached via SCSI to a Linux storage node server.
When I ran jbconfig, I specified
/dev/nst# where # was 0-3 for each device. I'm wondering what these
other modes do, and if maybe I should
be using one of those instead. I'm able to backup and recover fine to
these drives, but compression rates
seem low. Here are some of the volumes we've written to:
volume (%used) written
[...]
FLN027 65% 195 GB
INC001 full 329 GB
INC002 full 346 GB
INC003 full 292 GB
INC004 full 349 GB
INC005 100% 355 GB
> I thought SDLT II tapes were 300/600. With our old ATL P1000 library
that has SDLT 220 drives it was not uncommon to get
135-160+ GB on a SDLT 1 tape. That's nearly 1.5 times the 110 native
capacity on average. I'm not seeing anything near 1.5 times
(let alone twice) the capacity of the SDLT II tapes, however. That would
be 450 GB.
Yup, but the driver isn't going to control the compression algorithm or
anything like that. If you're getting anything above the native
capacity, then it must at least be enabling compression.
I copied the stinit.def file template from Quantum's site, and copied it
to /etc/stinit.def. It has the
following entry for the SDLT600:
# QUANTUM SDLT600
manufacturer=QUANTUM model="SDLT600" {
timeout=3600 # 1 hour timeout
long-timeout=14400 # 4 hour long timeout
can-partitions=0
mode1 blocksize=0 density=0x4A compression=1 # SDLT600 density,
compression on
mode2 blocksize=0 density=0x4A compression=0 # SDLT600 density,
compression off
mode3 blocksize=0 density=0x49 compression=1 # SDLT320 density,
compression on
mode4 blocksize=0 density=0x48 compression=1 # SDLT220 density,
compression on
}
There's your 0, 0l, 0m and 0a devices. You certainly want to be using
mode 1. Here's a page that mentions 'stinit -v -v' should show that
association more explicitly (although this file is 1-4 and the other bit
of output is 0-3, I think they should line up).
http://www.mail-archive.com/linux-setup AT senator-bedfellow.mit DOT
edu/msg03128.html
So am I to assume that nst0, 1, 2 and 3 would use mode 1, and nst0a
would used mode 2 and
nst0l would use mode 3 and then nst0m would use mode 4? How do you know
which mode
is assigned to which device: nst0, a, l or m? Are we correct to be using
nst0, 1, 2 and 3 then for hardware compression?
That's my understanding.
--
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
|
