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 AT VM.MARIST DOT EDU] On Behalf Of 
Sergio O. Fuentes
Sent: Friday, November 15, 2013 12:15 PM
To: ADSM-L AT VM.MARIST DOT 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