[ADSM-L] Deduplication "number of chunks waiting in queue" continues to rise?
2013-12-19 23:41:27
TSM 6.3.4.00 on Win2K8
Perhaps some of you that have dealt with the dedup "chunking" problem can
enlighten me.
TSM/VE backs up to a dedup file pool, about 4 TB of changed blocks per day
I currently have more than 2 TB (yep, terabytes) of volumes in that file pool
that will not reclaim.
We were told by support that when you do:
SHOW DEDUPDELETEINFO
That the "number of chunks waiting in queue" has to go to zero for those
volumes to reclaim.
(I know that there is a fix at 6.3.4.200 to improve the chunking process, but
that has been APARed, and waiting on 6.3.4.300.)
I have shut down IDENTIFY DUPLICATES and reclamation for this pool.
There are no clients writing into the pool, we have redirected backups to a
non-dedup pool for now to try and get this cleared up.
There is no client-side dedup here, only server side.
I've also set deduprequiresbackup to NO for now, although I hate doing that, to
make sure that doesn't' interfere with the reclaim process.
But SHOW DEDUPDELETEINFO shows that the "number of chunks waiting in queue" is
*still* increasing.
So, WHAT is putting stuff on that dedup delete queue?
And how do I ever gain ground?
W
**Please note new office phone:
Wanda Prather | Senior Technical Specialist | Wanda.Prather AT icfi DOT com
| www.icfi.com
ICF International | 443-718-4900 (o)
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [ADSM-L] Deduplication "number of chunks waiting in queue" continues to rise?,
Prather, Wanda <=
|
|
|