Hi Steve (and other who replied)!
The risk of fragmentation sounds reasonable. I will keep that in mind,
thanks!
Yes, I'm running two storage pool backups at the same time (my copypool
library only has two drives) and buying more drives is not an option, since
it's a 3494 frame. Expanding requires buying a drive frame and 3590 drives,
which are very expensive. This while my current TSM environment will have to
hold on for about half a year. We are currently working on a drastic TSM
redesign.
We are planning for a TSM 5.3 server on AIX 5.2 on a brand new P-Series
machine. We will attach more than one (probably 3) DS-series (formerly known
as FastT) SATA subsystems with a total amount of 200 Tb. online storage to
accommodate for our primary (file device class) storage pool.
We only ran into a nasty bug when using the file device class, so I hope IBM
will turn my PMR in an APAR and fix it as soon as possible...
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines



-----Original Message-----
From: Steve Schaub [mailto:Steve.Schaub AT HAWORTH DOT COM]
Sent: Thursday, January 13, 2005 21:32
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Enabling caching to shorten housekeeping


Eric,

The issues we had when we had caching turned on were:
1. Fragmentation of the the diskpool which led to a general slowdown in
processes.  This can be minimized if you have a regular schedule of
flushing the cache (turn it off and migrate down to zero).
2. TDP agents don't always play nice with diskpool using caching - some
algorithim issue that doesn't free up a big enough block and then kills
the backup when it runs out of room in the pool.

I'm assuming you are already multi-threading your stgpool backup and
migration, so the only suggestions I can offer are;
1. buy more tape drives and increase the multi-threads
2. buy tons of cheap disk and implement file-based stgpools.  This is
the approach we took and it cut our total housekeeping elapsed time by
75%.

Good luck!

Steve Schaub
Computer Storage Systems Engineer II
Haworth, Inc
616-393-1457 (desk)
616-886-8821 (cell)
Steve.Schaub AT Haworth DOT com
"Trials are inevitable.  We can curse them and grow bitter, or harvest
them and grow stronger"


-----Original Message-----
From: Loon, E.J. van - SPLXM [mailto:Eric-van.Loon AT KLM DOT COM]
Sent: Thursday, January 13, 2005 10:27 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Enabling caching to shorten housekeeping


Hi *SM-ers!
I'm currently struggling with the fact that I cannot run a backup
stgpool diskpool and a migrate diskpool (to empty it out for the next
client backup
cycle) sequentially no more. Migration would run well into the evening
and I would like it to be ready at 18:00 hours. I'm thinking about
turning on caching for my diskpool. If it works like I hope, TSM
migration empties out the diskpool, but leaving the actual data behind,
so a backup stgpool diskpool uses these cached copies, instead of
mounting all the tapes during a subsequent backup stgpool tapepool. In
that case, I can run migration and backup stgpool at the same time. Is
TSM working like this or will a cached object, once (logically)
migrated, be backed up from tape? Thank you very much for your reply in
advance! Kindest regards, Eric van Loon KLM Royal Dutch Airlines


**********************************************************************
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.
**********************************************************************