ADSM-L

Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe

2014-10-22 15:13:11
Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe
From: "J. Pohlmann" <jpohlmann AT SHAW DOT CA>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Oct 2014 12:11:55 -0700
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 AT VM.MARIST DOT EDU] On Behalf Of 
Prather, Wanda
Sent: October 22, 2014 11:50
To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf Of 
Martha M McConaghy
Sent: Wednesday, October 22, 2014 1:06 PM
To: ADSM-L AT VM.MARIST DOT 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.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