Hi Sergio, my first server started at 6.1 so it was all server side dedup. I have not let any of its clients do client side. The separation based on maxsize is working as designed.
My 2nd server started at 6.3 and I do use client side. The clients do not react well when a file bigger than the maxsize needs to be backed up. It gets backed up but the client does not reset for subsequent files which are under the maxsize. I have adjusted to this but making nextpools for the unlimited pool which recreate the maxsize separation during migration of the unlimited maxsize pool. Here is a script output of the storagepools in one of the newer servers - Name Numscr Device PoolSzGb PctUtil Migpr Next MaxSz --------------------- -------- ------------- ------------ -------- ------ ---------------- -------- BKP_1A 28 DD_L1 2094.6 5.1 4 BKP_2 1.00 BKP_1B 6 DD_L1 2003.0 0.8 4 BKP_2 1.00 BKP_2 405 DD_L2 46062.9 52.3 1 BKP_3 1.00 BKP_3 8 NDD_L3 22279.4 1.5 1 BKP_3A BKP_3A 0 DD_L2 0.0 0.0 1 BKP_3B 1.00 BKP_3B 121 NDD_L3 29347.5 25.2 1 BKP_4 BKP_4 0 LTO5A 0.0 0.0 1 BKP_3 is unlimited but when it migrates the files separate into bkp_3a with a maxsize of 1 GB and bkp_3b which is unlimited. The reclaim target pool for bkp_3a is bkp_2, so that gets all the files I intended to dedup back together. I reported the issue to IBM and I think it will be fixed in 6.3.5; I don't know if it is in 7.1, but it should be. Copypools go to virtual volumes hosted by a small server with a small tape library. Since the volumes are never marked off-site, reclamation doesn't recreate the unexpired files from the dedup'ed primary pools. And I wouldn't want this anyway. The point of the deduprequiresbackup server parameter is to have a version of the file in its original never-ripped-apart state. I have developed a process to reclaim the copypool volumes in time order because they are really stored on racked tapes. The reclaim command would jump all over the range of volumes causing constant requests for tapes to be entered. I don't actually do a reclaim process, instead I issue move data commands in the order that the volumes were created. Thanks, - bill -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Sergio O. Fuentes Sent: Friday, November 15, 2013 12:15 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM Dedup stgpool target Bill, Thanks for info. Just curious, are you utilizing source-side dedupe or relying on the TSM identify to identify all your duplicates (post-process)? How does the maxsize parameter interact with source-side dedup? I'll have to look that up. Eventually you have to reclaim your copy pools and based on your hierarchies, it looks like reclamation would be feeding off from the large 4TB drives. Have you had issues reclaiming from those pools? Thanks! Sergio