Try show dedupdeleteinfo - if there are chunks queued or threads actively working on deleting chunks, the volumes will remain.
Regards, Joerg Pohlmann -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: October 22, 2014 11:50 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Don't believe that. I have seen it before - if you can do a MOVE DATA, it isn't really empty. I think it has to do with dedup. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Martha M McConaghy Sent: Wednesday, October 22, 2014 1:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe Yup, they are really empty. /data0/00000D57.BFS DEDUPEPOOL FILE 50.0 G 0.0 Full tsm: TSMPRIMESERVER>q content /data0/00000D57.BFS Session established with server TSMPRIMESERVER: Linux/x86_64 Server Version 7, Release 1, Level 1.0 Server date/time: 10/22/2014 12:54:58 Last access: 10/22/2014 11:36:27 ANR2034E QUERY CONTENT: No match found using this criteria. ANS8001I Return code 11. Martha On 10/22/2014 12:08 PM, Michael Roesch wrote: > Hi Martha, > > have you run "query content" on some of the volumes to see, if they > are really empty? > > Michael > > On Wed, Oct 22, 2014 at 5:47 PM, Martha M McConaghy < > martha.mccona...@marist.edu> wrote: > >> We just installed TSM 7.1 during the summer and have been working on >> migrating our backups over from our old v5.5 system. We are using >> deduplication for our main storage pool and it seems to work great. >> However, I'm concerned about how it is using the "volumes" in the >> storage pool. Since we never ran v6, I don't know if this is "normal" >> or if we have stumbled upon a bug in 7.1. So, I figured I'd ask on >> the list and see if any of you have some insight. >> >> Our dedupe storage pool is dev class FILE, of course. It is set up >> to acquire new scratch "volumes" as it needs over time. Originally, >> I had the max scratch vols allowed at 999, which seemed reasonable. >> After about a month, though, we hit that max and I had to keep raising it. >> When I query the volumes belonging to this pool, I see many, many of >> them in full status, with pct util=0: >> Volume Name Storage Device >> Estimated Pct Volume >> Pool Name Class >> Name Capacity Util Status >> ------------------------ ----------- >> ---------- --------- ----- -------- >> /data0/00000B55.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000B8F.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000BCF.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000BD6.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C16.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C2A.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C63.BFS DEDUPEPOOL FILE 49.9 >> G 100.0 Full >> /data0/00000C72.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C79.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C84.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C8C.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C93.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000C9A.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000CA1.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> /data0/00000CB3.BFS DEDUPEPOOL FILE 50.0 >> G 0.0 Full >> >> Literally, hundreds of them. I run reclamations, but these volumes >> never get touched nor reclaimed. Seems to me that they should. I've >> gone over the admin guide several times, but have found nothing >> touching on this. We just applied the 7.1.1.0 updates, but that has >> not helped either. If I do a move data on each, they will disappear. >> However, more will return to take their place. Anyone seen this >> before, or have any suggestions? >> >> Martha >> >> -- >> Martha McConaghy >> Marist: System Architect/Technical Lead >> SHARE: Director of Operations >> Marist College IT >> Poughkeepsie, NY 12601 >> -- Martha McConaghy Marist: System Architect/Technical Lead SHARE: Director of Operations Marist College IT Poughkeepsie, NY 12601