Client-side dedup and simultaneous-write to a copy pool are mutually exclusive. You can't do both, which is the only theoretical way to enforce deduprequiresbackup with client-side dedup. I suppose IBM could enhance TSM to do a simultaneous-like operation with client-side dedup, but that's not available now. So, I'm not sure how the TSM server enforces deduprequiresbackup with client-side dedup. Ever since 6.1 I have always set that to NO anyway. I have dealt with the repercussions of that as well. Backup stgpool on dedup'd stgpools is not pretty.
I have made some architectural changes to the underlying stgpools and the 'backup stgpools' run pretty well, even with 1TB SATA drives. Two things I think helped quite a bit: 1. Use big predefined volumes. My new volumes are 50GB. 2. Use many filesystems for the devclass. I have 5 currently. I would use more if I had the space. Thanks! Sergio On 12/20/13 11:35 AM, "Prather, Wanda" <[email protected]> wrote: >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:[email protected]] >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" <[email protected]> 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 | [email protected] >>| www.icfi.com >>ICF International | 443-718-4900 (o) > >
