I have found the need to hunt down some non-compressible/dedupable data is landing on the DD appliance. I use this process, it isn't quick or easy, but it can point you to the client(s).
On the TSM server, do a "q dev f=d" and look for the sequential devices you have defined on the DD appliance. On the datadomain, do a "filesys show compression /backup/(yourvalue)" on all the TSM devices you have defined on the DD. - Look for the one that has the worst compression ratio or perhaps the one that is on a downward trend. On the TSM server, do a "q volhist ty=stgnew". Look for the volumes on the TSM device(s) you have defined on the DD. The newest ones are at the bottom of the list. On the datadomain, do a "filesys show compression /backup/(yourvalue)/(volumename)" i.e. "filesys show compression /backup/databases/00000621.bfs" Note that depending on the TSM version you are on, the TSM server may show the volume name in all CAPS, but the DD is actually all in lower case. Do this command for a bunch of volumes in your device class(es), you should start to get a picture of a some volumes that have substantially lower compression. On the TSM server, look to see what client data is on that those TSM volumes "q content /BACKUP/databases/00000621.BFS count=100" Note, if you have collocation set to "node or filespace", this makes it easy, because all the data for one node will be on the same volume, so you will have your offending client. If you have collocation set as "no, or group" on that storage pool, then you have to look at more volumes to get an idea of what TSM clients may or may not be involved. Once you think you have some suspect nodes, look at other volumes from that node: On the TSM server, do a "q nodedata (client) stg=(stgpool)". Look for some volumes that have a lot of that node's data on them. On the datadomain, do a "filesys show compression /backup/(yourvalue)/(volumename)" on the other nodes from this client and see if there is a trend. Hopefully, by the end of this treasure hunt, you have at least defined the TSM client(s) that seem to be putting the non-compressible/dedupable data. It is typically data that is already compressed in some format, i.e. certain JPG or WAV files, zip or RAR files, or perhaps DB dumps that are compressed as they are dumped out. Good Luck, Ben -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick Adamson Sent: Thursday, September 20, 2012 8:07 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Actual TSM client storage utilization using Data Domain I have a situation where I suspect one, or more, of my TSM clients is rapidly consuming large amount of storage space and am at odds of how to accurately determine the culprit. The TSM server is configured with a data domain dd880 as primary storage of the device type "file" so obviously when I query the occupancy table in TSM it provides raw numbers that do not reflect the de-dup and compression of the DD device. Querying compression on the DD only provides numbers per storage area, or context. Has anyone been found a way to determine the actual amount of storage that a particular client is using within data domain? All comments welcome..... TSM Server 5.5 on Windows and Data Domain ddos 5.1. ~Rick The BCI Email Firewall made the following annotations --------------------------------------------------------------------- *Confidentiality Notice: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute, and delete the original message. Thank you for your compliance. You may contact us at: Blue Cross of Idaho 3000 E. Pine Ave. Meridian, Idaho 83642 1.208.345.4550 ---------------------------------------------------------------------