ADSM-L

Re: Bad performance from tape to tape

2002-08-16 11:22:45
Subject: Re: Bad performance from tape to tape
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 16 Aug 2002 10:45:53 -0400
Eric, I AGREE!!

Another thing to remember, even if you have tapes sitting around for much
LESS than 10 years, you are probably upgrading the microcode levels of your
drives over time.  I DO NOT want to be in the position of trying to read a
tape that was created by drive microcode 10 revs back....
in theory it should work, but in practice, NOTHING GOOD WILL HAPPEN.

TSM reclamation is a pain sometimes, but one of the nice things about it is
that MOST of your data will gradually roll over and get rewritten to new
tapes over time.

Since we usually do 1 or 2 microcode upgrades per year, I have a script that
regularly checks the "date last written" on all my tapes, and if they get
more than 18 months old, I force a MOVE DATA.

One less thing I have to worry about, over time...

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************




-----Original Message-----
From: Loon, E.J. van - SPLXM [mailto:Eric-van.Loon AT KLM DOT COM]
Sent: Friday, August 16, 2002 7:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Bad performance from tape to tape


Hi *SM-ers!
Maybe this has been stated before, if so I missed that reply.
There is no media on the market that guarantees storage forever... I doubt
you will be able to restore an LTO tape 10 years from now. I've read
somewhere that even CD will not do, it's guaranteed for about 25 years or
so.
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: Bill Boyer [mailto:bill.boyer AT VERIZON DOT NET]
Sent: Thursday, August 15, 2002 22:37
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Bad performance from tape to tape


The original poster said his disk pool had CACHE=YES turned on. So for a
time a backed up file could reside in 3-different places....disk pool
cache..onsite tape..offsite tape. Normally when you think of reclamation it
is a tape-to-tape process, so I/we were generalizing.

The problems is that when the primay copy of the file is on a random access
disk storage pool, TSM does not use the MOVEBATCHSIZE and MOVESIZETHRESH
parameters to 'batch' the transactions. The reclamation process
moves/reclaims 1 file..updates the DB....moves another file...updates the
DB....etc.etc...

When CACHE=YES is on, then TSM will use the primary location with the best
performace...DISK. Even though the file is on the sequential onsite tape
media. CACHE=YES is good for restore performance, but when the storage pool
fills up during client backups, you have to overhead of TSM deciding which
CACHE'd files to throw away, throwing then away and then accepting the new
backup data.

A process we use is to do all the storage pool backup first thing in the
morning after the client backups are complete, but not do the migration
until later in the afternoon. This way last nights' backup data is still on
disk for restore performance, but then moved off before the next nights'
backups start. We've found that a lot of the onsey-twosy restores are
because the use hosed up his file today and needs it restored from last
nights' backup. This way it comes from disk, but you don't have the
CACHE=YES overhead and performance hit for reclamation.

Bill Boyer
DSS, Inc.
"Backup my harddrive?...How do I put it in reverse??" - ??

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Vos, F (Freek)
Sent: Thursday, August 15, 2002 12:08 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Bad performance from tape to tape


Hi Bill,

Reclamation is not only a tape to tape copy.
The changes to the TSM database are they holding down your speed ?
The amount of tape mounts, are there many ?
Do the disks and the tapeunits share the same SCSI adapter ?

Groet,

Freek.


-----Original Message-----
From: Bill Boyer [mailto:bill.boyer AT VERIZON DOT NET]
Sent: donderdag 15 augustus 2002 17:15
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Bad performance from tape to tape


The tape-to-tape operation that is adversely affected is reclamation. If the
primay location of a file is in a random access disk pool, then TSM does not
'batch' the files together. Each transaction is a single file. The primary
location can be a disk sequential access pool, but not random access. We
originally came across this with DIRMC. We had the primary a DISK pool and
then only created the copypool. The reclamation on the copypool tapes used
to take days. Opened a PMR with Tivoli and got the 'working as designed'
answer.

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Joe Pendergast
Sent: Thursday, August 15, 2002 9:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Bad performance from tape to tape


Is the disk pool cached?
I ran into a situation where the disk pool cache instead of tape was being
used.
This slowed my LTO drives to a crawl during certain operations.
I now varyoff the disk pools before I run the process with expected results
Don't forget to vary them back on at the end..
Note: the disk pool cache is a great help in restore time, but it can
adversely
the affect of what should be a tape to tape process.





Halvorsen Geirr Gulbrand <gehal AT WMDATA DOT COM> on 08/15/2002 03:00:23 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Joseph Pendergast/Corona/Watson)

Subject:  Bad performance from tape to tape



Hi All,
I have a performance problem when doing Space-Reclaamtion, or backup storage
pool, when TSM is copying data from one tape drive to the other.
Environment:
Windows 2K server, TSM 4.2.1.15.
Library, Compaq MSL5026, with 2 SDLT drives (Single Module Library).
SCSI Controller, Compaq 64-bit/66Mhz Dual Channel Wide Ultra3 SCSI Adapter
(Compaq version of Adaptec 39160)

Moving data from Disk to Tape runs with expected speed (8-10 MB/s).

>From Tape to tape speed is around 2MB/s. (50GB takes about 7-8hours.)

Does anyone know why? It is killing my daily operations.

Mvh
Geirr G. Halvorsen
TSM Enterprise Backup Specialist
WMdata Danmark A/S

==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.


==================================================================


**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential
and privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may
be disclosed, copied or distributed, and that any other action related to
this e-mail or attachment is strictly prohibited, and may be unlawful. If
you have received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. Koninklijke Luchtvaart
Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be
liable for the incorrect or incomplete transmission of this e-mail or any
attachments, nor responsible for any delay in receipt.
**********************************************************************

<Prev in Thread] Current Thread [Next in Thread>