Networker

Re: [Networker] Linux and stinit.def file?

2003-07-22 12:16:45
Subject: Re: [Networker] Linux and stinit.def file?
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Tue, 22 Jul 2003 12:16:37 -0400
Yeah, I always figured that if we wanted to go back and dork around with
those older tapes that a reboot without the stinit.def file would be
prudent. As such, recoveries of those tapes would work, but your tape
positioning by record would be disabled since the tape was created
without the stinit.def file (wrong blocking I guess). Of course, this
makes the process of getting to the right location on the tape rather
slow. It may even slow down the amount of time to do the recover once
there. But I concur that having the stinit.def file in place would
either cause problems or simply slow things down even worse than they
already would be with those older tapes. Of course, if you're talking
about tapes that old, then in our case, we'd be well beyond the browse
policy, so only a saveset recover would be used anyway. So perhaps  the
tape positioning by record is a moot point in that case?

We're running an STK L80 (4 LTO drives, 80 slot) and an ATL P1000 SDLT
(2 SDLT drives, 30 slot) on a Dell PowerEdge 2500 running Linux. This is
our storagenode server. The primary server is a Sun running Solaris. It
uses an older ATL P1000 DLT tape library (3 dlt 7000 drives, 30 slot).

George

Matthew Temple wrote:
>
> On Tue, 22 Jul 2003, George Sinclair wrote:
>
> > As near as I can tell, we still received the errors whenever we accessed
> > a tape that had been labeled from before the changes. This would occur
> > if we were recovering data or even recycling the tape since NetWorker
> > must read the old label first before doing anything. To be on the safe
> > side, I always re-labeled it a second time to make sure the message did
> > not come back. It never did. For a while I toyed with the idea of
> > removing the stinit.def file and attempting a recover on an older tape
> > versus a recover on the same tape with our current stinit.def file in
> > place. In other words, seeing if there's any difference in the recover
> > time from an older tape that had been created without the stinit.def,
> > trying both with the new stinit.def file and without, but I decided I
> > would cross that bridge if and when somoneone ever needed to recover
> > anything that old. No point worrying about it until then. No one has
> > ever needed any of those tapes. We've had many recovers since the
> > creation of the stinit.def, and no problems or errors while recovering.
>
> Thanks, and that's interesting information.   I believe I may have
> verified that there are "before stinit.def" and "after stinit.def"
> tapes as well as a few "with-and-without stinit.def" tapes  (those
> were partially used when I added the stinit.def entries.)   My first
> impression was that the tapes that couldn't be read any more were those
> transitional tapes.   I also noticed that booting without stinit.def
> allows reads of the older tapes.
>
> What sort of server are you running.   (We're running a Linux
> machine with a Qualstar 126-slot library, 2 AIT-3 drives and one
> AIT-2 drive. -- don't ask!)
>
> Legato is always an adventure, but, unlike, say, my experience
> with Arkeia (now fairly old, perhaps) when Networker claims to
> have b acked something up, it's ACTUALLY on the take.   We now have
> about 7 tb of real data on 12 tb's worth of disk space.
>
>                                                 mht
> >
> > George
> >
> > Matthew Temple wrote:
> > >
> > > Did you ever get an answer to this?  I may have a similar problem.
> > >
> > >                                         Matt Temple
> > >
> > > On Thu, 2 Jan 2003, George Sinclair wrote:
> > >
> > > > Will it be necessary to relabel a tape or label a "new" (unused) tape
> > > > for the new changes to take effect? In other words, let's suppose I add
> > > > the entries to the stinit.def file, reboot and then try to recover and
> > > > or write data to tapes. Will I still see the block error messages on
> > > > older tapes that were labeled from before the changes were made, but I
> > > > won't see them on tapes labeled after the changes were made or is it
> > > > retroactive?
> > > >
> > > > George
> > > >
> > > > Tim Mooney wrote:
> > > > >
> > > > > In regard to: Re: [Networker] Linux and stinit.def file?, Scott 
> > > > > Russell...:
> > > > >
> > > > > >On Tue, Dec 31, 2002 at 10:28:19PM -0500, George Sinclair wrote:
> > > > >
> > > > > >> The stinit man page does mention that 'revision' can be used, BUT 
> > > > > >> it
> > > > > >> does not indicate whether or not it should be in double quotes 
> > > > > >> like the
> > > > > >> model? Any thoughts?
> > > > > >
> > > > > >I didn't bother with a revision tag. They way I understood the
> > > > > >stinit(8) man page is that manufacturer, model, and revision can all
> > > > > >be used to identify a specific device, assuming you have multiple
> > > > > >device types.
> > > > >
> > > > > You're doing exactly what I would recommend -- don't specify the 
> > > > > revision
> > > > > *unless* it becomes important down the road to have a distinct entry 
> > > > > for
> > > > > a particular revision of your drives, such as if some firmware level 
> > > > > has
> > > > > a problem that can be worked around by changing the st parameters.
> > > > >
> > > > > > Since all of my drives were LTO I simply specified the
> > > > > >manufacturer and model and did not bother with a revision.
> > > > >
> > > > > This way you don't need to remember to update your stinit.def when you
> > > > > flash your drives to a new firmware level.
> > > > >
> > > > > Tim
> > > > > --
> > > > > Tim Mooney                              mooney AT 
> > > > > dogbert.cc.ndsu.NoDak 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
> > > > >
> > > > > --
> > > > > Note: To sign off this list, send a "signoff networker" command via 
> > > > > email
> > > > > to listserv AT listmail.temple DOT edu or visit the list's Web site at
> > > > > http://listmail.temple.edu/archives/networker.html where you can
> > > > > also view and post messages to the list.
> > > > > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
> > > >
> > > > --
> > > > Note: To sign off this list, send a "signoff networker" command via 
> > > > email
> > > > to listserv AT listmail.temple DOT edu or visit the list's Web site at
> > > > http://listmail.temple.edu/archives/networker.html where you can
> > > > also view and post messages to the list.
> > > > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
> > > >
> > >
> > > --
> > > =============================================================
> > > Matthew Temple                Tel:    617/632-2597
> > > Director, Research Computing  Fax:    617/582-7820
> > > Dana-Farber Cancer Institute  mht AT research.dfci.harvard DOT edu
> > > 44 Binney Street,  ML105      http://research.dfci.harvard.edu
> > > Boston, MA 02115              Choice is the Choice!
> >
>
> --
> =============================================================
> Matthew Temple                Tel:    617/632-2597
> Director, Research Computing  Fax:    617/582-7820
> Dana-Farber Cancer Institute  mht AT research.dfci.harvard DOT edu
> 44 Binney Street,  ML105      http://research.dfci.harvard.edu
> Boston, MA 02115              Choice is the Choice!

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Networker] Linux and stinit.def file?, George Sinclair <=