Odd storage pool bug?

jamesmacd40

ADSM.ORG Member
Joined
Apr 17, 2018
Messages
67
Reaction score
3
Points
0
PREDATAR Control23

running TSM 7.1.7.0 seeing an odd issue that when reclamation is happening on a stg pool that contains dedup.
Using traditional storage pools (no container pools) - identify processes run all the time.
Reclaim on a storage pool was started with a threshold of 75. volume 0000c065.bfs is showing 100% full with 76% reclaimable, however it was last written to yesterday so it is all new data.

issuing q vol against the volume during reclaim , the %util goes down and % reclaim goes up, but once % reclaim hits 100%, it goes to 26.

the thought is the original 76% reclaimable is calculated incorrectly, it should be near 0 and should not be picked for reclamation as it was just written to the day before. This weird bug ends up moving 100s of GB of data for no reason and takes a long time

pretty sure Deduplication is causing this, because this doesnt happen on a non-dedup pool during reclamation.

just wondering if anyone has seen this behavior and if there are any work around.. none of the 7.1.7.xxx fixes reference this and we are stuck at this version for 2 reasons.. Not ready for 7.1.8 or 7.1.9 due to the enhanced security features, and we are running on W2K8(limits the version we can go to) with non ideal disk structure for db and logs to upgrade any further...

thanks
 

Attachments

  • X1.TXT
    16.1 KB · Views: 3
Top