I am trying to determine the causes of two anomalies in the behavior of a deduplicated storage pool in our TSM test environment. The test environment uses TSM 6.2.5.0 server code running under zSeries Linux. The environment has been using only server side deduplication since early September. Some tests before that time used client side deduplication.
The first anomaly has to do with reclamation of the deduplicated storage pool. For the last several days 'reclaim stgpool' commands have ended immediately with the message: ANR2111W RECLAIM STGPOOL: There is no data to process for LDH. This was surprising, given the amount of duplicated date reported by 'identify duplicates' processes. Yesterday I discovered that the storage pool had several volumes that were eligible for reclamation with the threshold that had been specified in the 'reclaim stgpool' commands. There had been a successful storage pool backup after the then most recent client backup sessions. I was able to perform 'move data' commands for each of the eligible volumes. The second anomaly has to do with filling volumes. The deduplicated storage pool has 187 filling volumes with a reported occupancy of 0.0. Most of these also have the percentage of reclaimable space also reported as 0.0, and all have the percentage of reclaimable space below 20. Most of the last write dates are concentrated in three afternoons. I maintain a document in which I log changes in the test environment and observations of the behavior of the environment. This document does not show any change in the environment or any observed anomalies on the days when most of the low occupancy volumes were last written. The test environment has two collocation groups. I have verified that the deduplicated storage pool is configured for collocation by group and that every node is in one of the collocation groups. All of the volumes in the storage pool have an access setting of 'READWRITE'. I have tried performing 'move data' commands for a few of the low occupancy volumes. The test environment consistently allocated a new scratch volume for output rather than adding the contents of the input volume to one of the few filling volumes with substantial amounts of data or to one of the many other low occupancy volumes. Web searches for the ANR2111W message turned up nothing except reminders that a storage pool backup is needed before reclamation. Web searches for various groups of keywords related to the second anomaly have turned up nothing recognizably relevant. Thomas Denier Thomas Jefferson University Hospital The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.