Tim
This only affects the Capacity license model, not the old PVU model.
In my case all de-duplication and compression is performed by Data Domain on 
the back-end and as such TSM is unaware of it.
All data is ingested by the TSM server, and thus reported, as raw data.
Without compression and deduplication the reported numbers for the capacity 
license are significantly larger and reflected in our license costs.

Considering the cost of Data Domain, combined with the elevated license costs, 
I am re-evaluating options.

Rick Adamson

   

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Tim Brown
Sent: Thursday, May 14, 2015 10:33 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm and dedup hardware or software or both

Since TSM licensing is based on TB's backed up, Will the TSM costs rise If all 
the data to TSM's perspective is not deduped?

Tim

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Rick Adamson
Sent: Thursday, 14 May, 2015 9:48 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm and dedup hardware or software or both

Coincidently I am testing this now. We have historically used Data Domain for 
TSM storage using a FILE class storage pool. For best results Data Domain 
prefers data uncompressed and unencrypted. If like us you have a capacity 
license this tends to significantly increase the reported TSM storage and 
ultimately license costs.

At least for the time being the data will still need to rest on Data Domain. 
Test objectives are; compare deduplication results of TSM versus DD,  
associated storage requirements, performance, and associated costs (additional 
memory, DB & Log space, etc.  

Will report back on the test results.
Feedback welcome....

Rick Adamson

   

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Ryder, Michael S
Sent: Thursday, May 14, 2015 8:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm and dedup hardware or software or both

Hi Tim

We use native TSM deduplication (software).

It's generally accepted that you perform one or the other and not both.
This is because additional deduplication results in an additional latency and 
often results in zero or negligible improvements.  Deduplication functions as a 
result of finding repetitive patterns, and the result are blocks with little 
repetition.  Performing deduplication against disk or files that is already 
deduplicated (and now have few repeating patterns) is a waste of time and 
resources.

Best regards,

Mike Ryder
RMD IT Client Services

On Thu, May 14, 2015 at 8:44 AM, Tim Brown <TBrown AT cenhud DOT com> wrote:

> Can anyone provide insight to how they use deduplication within TSM.
>
> TSM with SW based deduplication, no HW deduplication
>
> TSM with no SW based deduplication, using HW deduplication
>
> TSM with both SW and HW deduplication
>
> The only major restriction that I have read is that TSM file based 
> primary storage pools should not be deduplicated at both SW and HW 
> levels.
>
> Any insights appreciated!
>
> Thanks,
>
> Tim Brown
> Supervisor Computer Operations
> Central Hudson Gas & Electric
>