This is *very* dependant on your tape library and tape systems. The example
I used is a worst-case for us - INCR-LT-COPY is not co-located and is the
result of copying all our AIX and NT incrementals. But the MAXIMUM mounts I
would expect for the move data for this tape would be 12. We have 9 NT
storage pool tapes and 3 AIX, and a move data will only process an input
tape once. This is 1,510 GB of data (LTO holds a *lot*).
The LTO tapes, in our environment, move data at about 15 to 20 GB per hour,
and the tape I was playing with had about 80 GB on it. I killed the process
as I normally wait til the tapes are at about 50 GB before reclaiming them.
Tom Kauffman
NIBCO, Inc
> -----Original Message-----
> From: Gerhard Wolkerstorfer
> [mailto:Gerhard.Wolkerstorfer AT T-SYSTEMS DOT AT]
> Sent: Monday, November 05, 2001 10:15 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Antwort: Re: TSM annoyances
>
>
> I don't know the problem of John, but I do know, that a
> ONSITE "Move Data" of a
> 22% utilized "full" Volume will take approx. 30 minutes and
> max. 3 Input-Mounts.
> Let's say, your Primary Onsite Pool is collocated and your
> Backup OFFsite Pool
> isn't (as usual) =>
> If you do a OFFSITE "Move Data" of the same (Copy) Volume, it
> will take up to
> many many hourse because of (maybe) hundred mounts (or even
> more!) of Primary
> Volumes with Forwarding and Rewinding the whole time....
> That's annoying to me.....
> And I guess there's no solution for that, or is there any ??
>
> Gerhard Wolkerstorfer
>
>
>
>
>
> KauffmanT AT NIBCO DOT COM (Kauffman. Tom) am 05.11.2001 14:22:13
>
> Bitte antworten an ADSM-L AT VM.MARIST DOT EDU
>
> An: ADSM-L AT VM.MARIST DOT EDU
> Kopie: (Blindkopie: Gerhard Wolkerstorfer/DEBIS/EDVG/AT)
>
> Thema: Re: TSM annoyances
>
>
>
> John, you don't need to bring copypool tapes back on site to
> reclaim them.
> Just do a "move data" on the off-site volume and TSM will
> rebuild it from
> the original tapes in the library.
>
> Tom Kauffman
> NIBCO, Inc
>
> > -----Original Message-----
> > From: Johnn D. Tan [mailto:jdtan AT MED.CORNELL DOT EDU]
> > Sent: Friday, November 02, 2001 7:39 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: TSM annoyances
> >
> >
> > 1. Yet their device support website
> >
> (http://www.tivoli.com/support/storage_mgr/devices/all.html) lists the
> > element matrix for Gator, where slot 1 is element 1, but
> TSM actually
> > sees it as 1 + 29, or 30. And drive 1 is supposed to be 646, but TSM
> > sees it as 646 + 29, or 675. Again, despite their own matrix,
> > TSM seems
> > to have added 29 to the element addresses they list.
> >
> > 2. The reason I do "move data" is to consolidate the data that is
> > offsite. So, if I have a volume offsite that is
> > "under-utilized" (let's
> > say only 22% utilized), then I would want to check that tape
> > in, and do
> > a "move data" onto a pool-copy "filling" tape. But it won't
> > let me do a
> > "move data" unless the tapes associated with that one are
> also in the
> > library.
> >
> > 3. Yes, as I mentioned, it's most likely a SpectraLogic issue. Just
> > wanted to see if other folks were having similar issues.
> >
> > johnn
> >
> >
> >
> > On Friday, November 2, 2001, at 05:04 PM, George Lesho wrote:
> >
> > > 1.,The element numbers below 31 are associated with bulk
> > load, I/O port
> > > and
> > > other functions on my IBM 3575L32 Magstar tape library.
> Not Tivoli's
> > > fault
> > > or responsibility how the element numbers are mapped.
> > > 2. I let TSM worry about where it sticks the data on the tapes
> > > 3. Speak to your library vendor and ask them why their
> device driver
> > > microcode doesn't work right. The IBM Magstar doesn't
> > behave this way.
> > >
> > > George Lesho
> > > AFC Enterprises
> > > Storage/System Admin
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Johnn D. Tan" <jdtan AT MED.CORNELL DOT EDU>@VM.MARIST.EDU> on
> 11/02/2001
> > > 03:47:23 PM
> > >
> > > Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > >
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > cc: (bcc: George Lesho/Partners/AFC)
> > > Fax to:
> > > Subject: TSM annoyances
> > >
> > >
> > > I have a few annoyances with Tivoli -- not many, as it's a great
> > > product, just a handful.
> > >
> > > 1) We have TSM 4.1.3 server connected to SpectraLogic Gator/64000.
> > > Despite what Tivoli says on their website, the element
> > number of Slot 1
> > > in the library is not 1, but 30! This is very annoying!
> If I do a "q
> > > libv lib1" and look up a volume's home element, I have to
> > subtract 29 in
> > > order to really know what slot it's in on the library. Can this be
> > > corrected so that it is what Tivoli's website says it
> > should be -- i.e.,
> > > element 1 matches slot 1?
> > >
> > > 2) Is there a simple way to find out which volumes are
> > associated to any
> > > other? For instance, let's say I have to do a "move data"
> on 000115.
> > > Right now, here's what I do:
> > > q content 000115 count=-1 f=d
> > > q content 000115 count=1 f=d
> > > If either one of these has a segment 1/1, then
> everything's
> > > great,
> > > as there is no associated volume. But if either or both
> have 1/2 (or
> > > 2/2) then I have to issue:
> > > audit v 000115
> > > And find the associated volume. The catch is, if
> > there are *two*
> > > associated volumes, you have to check one of them in first
> > and update
> > > its status, before you can do another audit to find the
> > other associated
> > > volume.
> > > Is there any way to find these associated volumes
> > in one swift
> > > command?!
> > >
> > > 3) [I think this is more a SpectraLogic issue, but I'll gripe
> > > anyway ;).] When I want to "bulk load" a bunch of tapes
> > into the Gator
> > > tape library, I have to make sure no tapes are mounted in
> > the drives.
> > > Otherwise, the bulk load will just blindly put the new
> > tapes into the
> > > slots of the tapes in the drive. Doesn't TSM "talk" to the
> > tape library
> > > and tell it the home elements (or slots) of the tapes that
> > are mounted
> > > in the drives, so that the robotic picker won't put tapes
> into those
> > > slots??
> > >
> > > Thanks for any advice.
> > > johnn
> > >
> >
>
|
