ADSM-L

Re: Reporting anomaly - EST CAPACITY for sequential storage pools?

2006-11-22 11:51:28
Subject: Re: Reporting anomaly - EST CAPACITY for sequential storage pools?
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Nov 2006 11:50:55 -0500
Thanks for your reply.
The MAXCAP for the device class is 204800.
The numbers are much closer to the real file sizes, but still too high:

Here are my numbers::
 
>select * from stgpools where stgpool_name='BKFPOOL' 
 
    STGPOOL_NAME: BKFPOOL
        POOLTYPE: PRIMARY
        DEVCLASS: EMCSTORE
 EST_CAPACITY_MB: 257300.5
 
Now if you take 257300 and divide by 1024, you get 251.2.
But when I enter q stgpool, the results show:
 
Pool Name      Class Name              EstCap
------------------------------------------------------
BKFPOOL       EMCSTORE             257G
 
So that looks like they divided by 1000 instead of 1024.  But I still
can't figure out where the 257300 comes from.


 
q devclas EMCSTORE f=d
             Device Class Name: FILE
        Device Access Strategy: Sequential
            Storage Pool Count: 4
                   Device Type: FILE
                        Format: DRIVE
         Est/Max Capacity (MB): 204,800
                   Mount Limit: 200 
 
When I query the VOLUMES, est cap comes out exactly the same whether I
use Q vol or a SELECT:  
 
>select volume_name,est_capacity_mb,status from volumes where
stgpool_name='BKFPOOL'
 
VOLUME_NAME                 EST_CAPACITY_MB     STATUS
------------------     --------------------     ------------------
BKFVOL00001                        67986.4        FULL
BKFVOL00002                        68000.0        EMPTY
BKFVOL00003                        68000.0        FILLING
BKFVOL00004                        56988.9        FULL
 
ANS8000I Server command: 'q vol stgpool=bkfpool'
 
Volume Name                  Storage         Device         Estimated
Pct      Volume
                             Pool Name       Class Name      Capacity
Util      Status
------------------------     -----------     ----------     ---------
-----     --------
BKFVOL00001     BKFPOOL       EMCSTORE                67986.4      68.5
Full
BKFVOL00002     BKFPOOL       EMCSTORE                 68000.0       0
EMPTY

BKFVOL00003     BKFPOOL       EMCSTORE                 68000.0
36.5     FILLING
BKFVOL00004     BKFPOOL       EMCSTORE                  56988.9
90.2      FULL
 
dir
blah         71,303,168,000    bkfvol001     (68000 MB) 
blah         71,303,168,000    bkfvol002     (68000 MB)
blah         71,303,168,000    bkfvol003     (68000 MB)
blah         59,768,832,000     bkfvol004    (57000 MB)


If I divide by 1024/1024/1024, the numbers from DIR add up to 254 GB.
I don't see how TSM is coming up with 257,300 in Q stgpool.

Thanks for any hints!

Wanda


  

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David E Ehresman
Sent: Monday, November 13, 2006 11:03 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Reporting anomaly - EST CAPACITY for sequential storage
pools?

What do you have defined for the MAXCapacity for for the DEVCLASS?  I
would have thought the Estimated Capacity for the storage pool would be
the number of volumes times the MAXCapacity of the DEVC.

David

>>> "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU> 11/10/2006 3:50 PM >>>
Well, I'm confused.
TSM 5.3.3.0 on Windows.

One of my TSM servers has 3 primary sequential pools on disk.
(Devclass type = FILE).

The volumes are preallocated files created with DEFINE VOLUME, so
MAXSCRATCH=0 for the pool.
There have been no volumes added/deleted for weeks.

One of the pools is 254 GB, one is 7142 GB, one is 25TB (actual bytes,
calculated by summing up values for each file from Windows Properties).

Can anybody tell me how the ESTIMATED CAPACITY for the pool is
calculated?

All three are coming up with Estimated Capacity of MORE GB than are
actually available in the pool.
I get the same results from Q STGPOOL, or from SELECT * from STGPOOLS.

For example, Q STGPOOL shows the 1st pool as 257 GB, the second as 7551
GB.

None of the hits I found on ibm.com seemed to address this, and all
should have been fixed at 5.3.3.0.

Anybody else figured this out?

Wanda Prather
"* I/O, I/O, It's all about I/O *"  -(me)

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