ADSM-L

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

2014-10-22 14:50:27
Subject: Re: [ADSM-L] TSM 7.1 usage of volumes for dedupe
From: Steven Langdale <steven.langdale AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Oct 2014 19:48:47 +0100
What's your colocation set too for that stgpool?
On 22 Oct 2014 16:50, "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
>

<Prev in Thread] Current Thread [Next in Thread>