Also, remember, (if you are running client compression) that the
preallocation performed against the disk will be 100% of how big the file
is on your host system.
ALSO if you are using TDP/R3 and it is greater than tdpr3 v3.2.0.11 it will
clear cache and preallocate at a rate of 110% unless you alter the
environment variable that adjusts that overage percentage.
So, if you are running 10 concurrent multiplexed sessions each pushing two
(2) 4 GB files, that is 4*2*10*1.10 = 88 GB of diskpool space required,
even though the files might really only occupy 25 GB of storage pool space
due to client compression.
I have that problem of folks cranking up their number of concurrent
processes and rolling directly to tape... (sigh!)
Dwight E. Cook
Systems Management Integration Professional, Advanced
Integrated Storage Management
TSM Administration
(918) 925-8045
PAC Brion Arnaud
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ALPINA.COM> cc:
Sent by: "ADSM: Subject: Re: Multithreaded session
writes on tape although primary pool is on disk ...
Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
04/05/2004 08:26
AM
Please respond to
"ADSM: Dist Stor
Manager"
Richard, Matt,
Thanks for your input : looks like I'll have to expand my disk pool, or
diminish it's high mig percent to avoid this kind of situation ...
Regards.
Arnaud
***********************************************************************
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: [EMAIL PROTECTED]
***********************************************************************
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: Monday, 05 April, 2004 14:36
To: [EMAIL PROTECTED]
Subject: Re: Multithreaded session writes on tape although primary pool
is on disk ...
...
>Since I increased this resourceutilization parameter, it looks like the
>client regularly sends it's backups directly to tapelto1_aix ...
This is a classic situation where the disk pool is undersized relative
to demand: it fills (perhaps helped along by stpool caching overhead)
and TSM rules have the data go to the next stgpool in the hierarchy.
Transaction sizing and client-server size anticipations are also
factors. The cure is to have a generous disk storage pool, unless you
can identify other contributing factors in your configuration
(compression, etc.). Disk is cheap, so go for it.
Richard Sims
