Hi Wanda, 

Expire Inventory is queuing chunk for deletion. 

See the Q PR output when, at the end of the expire inventory process, the total 
numbers of nodes have been reached. No more deletion of objects occurs, but 
SHOW DEDUPDELETEINFO shows that the deletion threads are still working, queuing 
and deleting chunks. This activity does not appear "externally" and consumes 
most of the expire inventory time.

Let's try with deduplication disabled (dedup=no) for that pool (?).

Regards, 
Erwann



"Prather, Wanda" <Wanda.Prather AT ICFI DOT COM> a écrit :
>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)

-- 
Erwann SIMON
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.