Sorry for some of the duplicate postings, but it appeared that some of
my replies
were not getting distributed. I guess it was just lag time.
Would these two operations be equivalent?:
1. mt -f /dev/nst0 compression 0
tar cvf /dev/nst0 /tmp/dir
2. tar cvf /dev/nst0l /tmp/dir
I'm thinking they would both accomplish the same thing since the device
/dev/nst0l is defined in /etc/stinit.def as:
mode2 blocksize=0 density=0x48 compression=0 # SDLT220 density,
compression off
and 'stinit -v -v' reports:
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
Of course, that works for tar, or maybe NetWorker via the CLI wherein
you're specifying '-f /dev/device_name', but if you wanted, for
whatever reason, to temporarily use no-compress with NetWorker via the
GUI instead, then first running the mt command to toggle the
compression on or off as needed would make more sense because otherwise
you'd have to reconfigure the jukebox every time you wanted
to switch back and forth between the stinit.def mode 1 devices
(/dev/nst#) and the mode 2 devices (/dev/nst#l). That right?
Seems it would make more sense if they just made the darn modes 0-3 for
stinit.def, too, but maybe its akin to a 30 slot tape
library wherein the library numbers its slots 0-29, and the software
sees it as 1-30.
George
Darren Dunham wrote:
1. Since stinit reports 4 modes from 0-3, but our stinit.def file
numbers these modes from 1-4, SHOULD
I edit the stinit.def file to match this so it, too, numbers them from
0-3, or does stinit figure that out?
No, I don't think so. That's the output I always see, so I just assume
that it's a reporting difference.
Again, I'm using /dev/nst0, 1, 2 and 3 for my 4 devices, but if stinit
thinks this each of those is mode 0 then how could
it be assigning it properly if the stinit.def file doesn't have a line
for mode 0?
One utility calls the first slot 0, one calls it 1. It's still the
first slot. I don't think you have anything misconfigured.
When I run 'mt -f /dev/nst0 status' against drive 1, with a loaded
NetWorker labeled tape, it reports code 0x4a, so it's obviously picking
up one
of the first 2 lines from the stinit.def file, and since we're seeing
more than 300 GB on some tapes I would think it must be using line 1
(mode 1).
Me, too.
2. We've done NetWorker recovers on these new SDLT 600 drives using
older SDLT 1 tapes that were written on SDLT 220 drives,
Everything works fine, but the device names were still /dev/nst0, 1, 2
and 3. If stinit does think this is mode 1 how was
it able to read the tape since I didn't use /dev/nst0a (mode 4)? Does it
know to jump down to the 220 definition and use
the mode 1 listed there instead of the mode 4 listed under the 600
definition?
The mode is given to the device by the driver. It's up to the device
what to do with it. The density only matters when writing block 0 to
the tape. All later writes follow that density.
(compression/non-compression can be changed though). All reads simply
work if the device is compatible. The density/compression settings are
ignored.
--
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
|
