Woo hoo! That's great news. Will open a ticket and escalate. Also looking at client-side dedup, but I have to do some architectural planning, as all the data is coming from one client, the TSM VE data mover, which is a vm.
Re client-side dedup, do you know if there is any cooperation between the client-side dedup and deduprequiresbackup on the server end? I have assumed that the client-side dedup would not offer that protection. W -----Original Message----- From: Sergio O. Fuentes [mailto:sfuen...@umd.edu] Sent: Friday, December 20, 2013 10:39 AM To: ADSM: Dist Stor Manager Cc: Prather, Wanda Subject: Re: [ADSM-L] Deduplication "number of chunks waiting in queue" continues to rise? Wanda, In trying to troubleshoot an unrelated performance PMR, IBM provided me with an e-fix for the dedupdel bottleneck that it sounds like you're experiencing. They obviously will want to do their due-diligence on whether or not this efix will help solve your problems, but it has proved very useful in my environment. They even had to compile a solaris e-fix for me, cause it seems like I'm the only one running TSM on Solaris. The e-fix was very simple to install. What you don't want to do is go to 6.3.4.2, unless they tell you to because the e-fix is for that level (207). Don't run on 6.3.4.2 for even a minute. Only install it to get to the e-fix level. Dedupdel gets populated by anything that deletes data from the stgpool, I.e. move data, expire inv, delete filespace, move nodedata, etc. We run client-side dedupe (which works pretty well, except when you run into performance issues on the server) and so our identifies don't run very long, if at all. It might save you time to run client-side dedupe. BTW, when I finally got this efix and TSM was able to catch-up with the deletes and reclaims as it needed to, I got some serious space space back in my TDP Dedup pool. It went from 90% util to 60% util (with about 10TB of total capacity). What finally really got me before the fix was that I had to delete a bunch of old TDP MSSQL filespaces and it just took forever for TSM to catch up. I have a few deletes to do now, and I'm a bit wary because I don't want to hose my server again. I would escalate with IBM support and have them supply you the e-fix. 6.3.4.3 I don't think is slated for release any time within the next few days, and you'll just be struggling to deal with the performance issue. HTH, Sergio On 12/19/13 11:35 PM, "Prather, Wanda" <wanda.prat...@icfi.com> wrote: >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.prat...@icfi.com >| www.icfi.com >ICF International | 443-718-4900 (o)
