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.mcconaghy AT marist DOT 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