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@VM.MARIST.EDU] On Behalf Of Ryder, Michael S Sent: Thursday, May 14, 2015 8:59 AM To: ADSM-L@VM.MARIST.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 <tbr...@cenhud.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 >
