Active Data Calc Discrepancy? Please help!

jonathan274

ADSM.ORG Member
Joined
May 7, 2009
Messages
51
Reaction score
0
Points
0
Background:
We are trying to do sizing calculations for an Active Data Pool in TSM.

Problem:
I have noticed that performing a preview of several nodes to export the active data shows a very large discrepancy in the numbers TSM indicates would be moved versus the amount of data currently in existence on the server. For example one of the Win 2003 systems has 32GB currently in use on the system but the export node command reports only 1GB of active data for the node. Can anyone explain why there is such a large discrepancy?

05/06/2009 13:25:25 ANR2017I Administrator DC170 issued command: EXPORT NODE node.domain.com FILED=BACKUPActive PREVIEW=YES (SESSION: 97566)

05/06/2009 13:26:33 ANR0986I Process 1391 for EXPORT NODE running in the BACKGROUND processed 8537 items for a total of 1,040,086,124 bytes with a completion state of SUCCESS at 13:26:33. (SESSION: 97566, PROCESS: 1391)

12:01:05 PM TSMPROD : q filespace node.domain.com

Node Name Filespace FSID Platform Filespace Is Files- Capacity Pct
Name Type pace (MB) Util
Unicode?
--------------- ----------- ---- -------- --------- --------- ----------- -----
node.domain.C- SYSTEM 1 WinNT SYSTEM Yes 0.0 0.0
OM STATE
node.domain.C- SYSTEM 2 WinNT SYSTEM Yes 0.0 0.0
OM SERVICES
node.domain.C- \\demx22\e$ 3 WinNT NTFS Yes 29,998.0 3.6
OM
node.domain.C- \\demx22\c$ 4 WinNT NTFS Yes 10,002.0 79.8
OM
node.domain.C- ASR 5 WinNT NTFS Yes 0.0 0.0
OM
node.domain.C- \\demx22\d$ 6 WinNT NTFS Yes 99,998.0 25.5
OM
 
I am in the middle of moving some of my nodes into a policy domain that contains an active data pool (on a VTL) and I have found that the filespace table is correct. If you plan your active data pool to be able to hold all the data from a node listed in the filespace table, you should be right.

-Aaron
 
Thanks for the quick response! Good to know from someone that has done this that the filespace table is a good indicator for planning purposes, however, it is still odd that the export node with preview command would display such an odd number. I'd be interested to know if anyone else has seen this or has an explanation for it.
 
I can't explain the export issue either. From my test below, the export should have ~100GB in it, not ~45GB

Code:
05/07/09   13:40:46      ANR0986I Process 8336 for EXPORT NODE running in the
                          BACKGROUND processed 276068 items for a total of
                          46,368,953,318 bytes with a completion state of SUCCESS
                          at 13:40:46. (SESSION: 154897, PROCESS: 8336)


Node Name           Filespace       FSID     Platform     Filespace     Is Files-        Capacity       Pct
                    Name                                  Type            pace               (MB)      Util
                                                                        Unicode?
---------------     -----------     ----     --------     ---------     ---------     -----------     -----
RIDMSDAT14          SYSTEM             1     WinNT        SYSTEM           Yes                0.0       0.0
                     SERVICES
RIDMSDAT14          \\ridmsdat-        2     WinNT        NTFS             Yes           16,002.2      93.3
                     14\c$
RIDMSDAT14          \\ridmsdat-        3     WinNT        NTFS             Yes            1,004.0       5.3
                     14\d$
RIDMSDAT14          \\ridmsdat-        4     WinNT        NTFS             Yes          280,017.9      34.4
                     14\e$
RIDMSDAT14          SYSTEM             5     WinNT        SYSTEM           Yes                0.0       0.0
                     STATE
RIDMSDAT14          ASR                6     WinNT        NTFS             Yes                0.0       0.0
RIDMSDAT14          HSM-E$             7     WinNT        API:TSM          Yes              283.4     100.0
                                                           HSM Cli-
                                                           ent for
                                                           Windows

but when I look at the occupancy for my active data pool, I see:
Code:
tsm: BMCF4N1>select sum(physical_mb) from occupancy where node_name='RIDMSDAT14' and stgpool_name='RIDNT001_ENGA_POOL01'

                       Unnamed[1]
---------------------------------
                         45795.40

tsm: BMCF4N1>
which matches the export fairly closely. (44,220MB in export)

Maybe my method was wrong and the export is the better estimate tool.

-Aaron
 
What is the retention values on node's policy domain. You're previewing the export of FILED=BACKUPActive - which is only the Active copies of files. If you have large values for the RetE, RetO, VerE, & VerD parameters on management class copygroup, you could have large amount of Inactive versions that the export isn't processing. That's the reason for difference. Filespace occupancy is going to show total of all data, Active & Inactive for each file system. The export is just looking at the Active version.
 
Aaron/Jonathan,

Could the discrepancy be the affects of

- client compression (if its enabled, the space in tsm occupancy will be less - maybe much less)
- excludes/includes (less data will be stored in tsm than really in filesystem after exclusions)

I would expect the export output to be correct really ... but I guess there can always be bugs.
 
The host I used for comparison does not have compression enabled (the tape drives do tho) and there is not much in the exclude list except things like the Windows Swap file.

I originally thought the occupancy table would be the faster/easier way to look at active data but I think the export is the more correct answer.

-Aaron
 
Back
Top