Occupancy discrepancy?

[ldmwndletsm]

Can someone help me here? This is on Linux. Maybe the answer is plainly obvious?

I see a much larger value reported for the physical size than the file system is using. I've seen this on a number of file systems, and there have been no changes to these file systems since the first-time fulls. No deletions. no additions, no metadata changes, nothing. I checked the ctime for everything under these, and the most recent change of status time is well before I ran the first-time fulls. The dsmsched.log file reports that incrementals have run with success every night since, and there have been no reported entries (empty) other than the usual two messages thus:

2020-07-22 21:05:00 Incremental backup of volume '/filesystem1'
2020-07-22 21:16:19 Successful incremental backup of '/filesystem1'

For example, file system1 is reported (df -hlP) as 1.7 TB used. query occupancy nodename filespace1 reports thus:

Number of Files=304,785
Physical Space Occupied (MB)=1,820,070.7
Logical Space Occupied (MB)=1,820,070.7

That's about right, and I ran a find command against the file system (find /filesystem1 | wc) , and it reports 304785 entries, all good. However, for file system2 (also 1.7 TB used), I see this:

Number of Files=367,377
Physical Space Occupied (MB)=2,255,940.2
Logical Space Occupied (MB)=2,255,940.2

The number of files matches what a find reports, but TSM reports a little over a 500 GB increase versus what the OS reports. I see this on a bunch of them, but some are around what I would expect. We are using compression on the client.

 

[ldmwndletsm]

I note that the logical and physical space match in all cases as there have been no deletes or expires. We are not using deduplication.

 

[dicowins]

Have you considered "Inactive" files that havent expired yet? It will store all active versions + Inactive versions that havent expired yet. All depends on your Policies.