Networker

Re: [Networker] Need help with stinit.def for LTO-3

2007-01-30 23:19:16
Subject: Re: [Networker] Need help with stinit.def for LTO-3
From: Tim Mooney <Tim.Mooney AT NDSU DOT EDU>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Tue, 30 Jan 2007 22:09:59 -0600
In regard to: Re: [Networker] Need help with stinit.def for LTO-3, George...:

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.


From what I read in the stinit man page, the default is to use the device-specific addresses. So, if we set this to 1, then we will be
using Logical block addresses instead. If we change this, should we
still be able to recover data that was written to tape when the value
was previously remarked out (i.e.  set to use device-specific
addresses.)?

I don't know for certain, but I don't think it would cause the kind of
problem you're thinking of.  If you test it, please report back to the
list.

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.


Good point. Maybe I'll risk changing it. Again, though, I wonder how changing this might effect our ability to recover data from tapes that were written
when these values were previously set to 0?

I'm about 99% certain here that it won't make a difference.

It's odd, though, because the current documentation that Quantum has,
and what you use for your HPs, and one other source I found all indicate
that LTO3, 2 and 1 should use 0x44, 0x42 and 0x40 for the density codes
respectively. However, the older documentation
that Legato has that someone else posted earlier (ftp://ftp.legato.com/pub/HW_Support/compatguide/stinit.def)
indicates density=0x00 for both LTO-1 and LTO-2 for IBM and HP.

I think I can solve that mystery.  I'm almost positive that density 0x00
means "whatever the default for the hardware is".  For LTO3, that will
be LTO3 mode *unless* you've configured your drives (in the old days
tape drives could be configured to write in a non-default density via dip
switches, I've never looked to see if our LTO3 drives have anything of
the sort) to default to some other density.  Tape drives within a library
might be settable to a different default density via the library control
panel or configuration interface.

Either way, 0x00 means "it's up to the hardware".

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