Well, I guess I will answer my own question....
It looks to be a display bug/limitation on the server, as when I
grab the data from the occupancy table with a SQL command it looks
right:
tsm: TSMHOST3>select physical_mb from occupancy where node_name like
'BOFS8-X'
PHYSICAL_MB
------------
51827269.94
The odd thing is that I checked a couple of the other servers
with multi-TB of archived data and they don't seem to have the same
problem...
Odd...
Ben
> -----Original Message-----
> From: bbullock
> Sent: Wednesday, September 29, 2004 2:31 PM
> To: 'ADSM: Dist Stor Manager'
> Subject: Occupancy differences.
>
> Here is a strange one:
>
> We all see differences between the "q auditocc" command and the
> "Q occ" command, but they are typically rather small.
>
> On this one host, where all it does is archive some data that
> resides on a NetApp, there is a significant difference. The occ shows
> about 8.8TB and the auditocc shows 51TB:
>
>
> tsm: TSMHOST3>q occ BOFS8-X
>
> Node Name Type Filespace FSID Storage Number of Physical
> Logical
> Name Pool Name Files Space
> Space
> Occupied
> Occupied
> (MB)
> (MB)
> ---------- ---- ---------- ----- ---------- --------- ---------
> ---------
> BOFS8-X Arch /netapp/b- 1 NOCOPY_TA- 143,633 8,874,745
> 8,874,745
> ofs8/vol- PEPOOL .70
> .70
> /bofs8vo-
>
> l2/X_-
> backup
>
>
> tsm: TSMHOST3>q auditocc BOFS8-X
> License information as of last audit on 09/29/04 at 14:21:04.
>
> Node Name Backup Archive Space-Managed
> Total
> Storage Storage Storage Used
> Storage
> Used (MB) Used (MB) (MB)
> Used (MB)
> ----------------------------------- --------- --------- -------------
> ---------
> BOFS8-X 0 51,824,41 0
> 51,824,41
> 9
> 9
>
>
> Quick math of the number of tapes and their capacity comes up
> with about 50TB. So it looks like the auditocc is on the money, but
> the occ is way off...
>
> Anybody else seen anything like this?
>
> Thanks,
> Ben
