I can assure you that compression was NOT part of the earlier releases on 7.1.5 on AIX. I had to painfully tear down a system we were trying to convert to because compression was not included in the early 7.1.5 releases and dedup alone was not meeting saving expectations.
David -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Del Hoobler Sent: Monday, August 22, 2016 10:02 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] deleing data from a containerpool Minor correction. Inline compression for container pools was added in March in 7.1.5. IBM Spectrum Protect 7.1.5 - Inline compression: - Performed in-line after deduplication to provide additional storage savings - Negligible impact on resources – uses latest and most efficient compression algorithms - Can potentially double (or more) your storage savings after deduplication Del ---------------------------------------------------- "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 08/22/2016 09:53:08 AM: > From: "Loon, Eric van (ITOPT3) - KLM" <eric-van.l...@klm.com> > To: ADSM-L@VM.MARIST.EDU > Date: 08/22/2016 09:53 AM > Subject: Re: deleing data from a containerpool > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > Indeed, TSM 7.1.0 to 7.1.5 only supported deduplication, additional > compression was introduced in 7.1.6. > Kind regards, > Eric van Loon > Air France/KLM Storage Engineering > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of David Ehresman > Sent: maandag 22 augustus 2016 15:12 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: deleing data from a containerpool > > At the most recent levels of TSM, it both dedups and compresses but > make sure you are at a level that does both. There was a level that > only did dedup but not compression. > > David > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of Rhodes, Richard L. > Sent: Monday, August 22, 2016 9:07 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] deleing data from a containerpool > > >But I totally agree, everyone who is using file device > > >classes or expensive backend deduplication (like Data Domain or Protectier) > > >should seriously consider switching to container pools. > > > > > > We currently use DataDomains. > > With a DD it dedups what it can, then compresses the rest. > > Does TSM also try and compress what is leftover after dedup? > > > > > > > > > > > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of Loon, Eric van (ITOPT3) - KLM > > Sent: Tuesday, August 16, 2016 3:39 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: deleing data from a containerpool > > > > Hi Stefan! > > Our database is on SSD in an IBM V3700, but the time needed for a > del filespace can be significant though. But I totally agree, > everyone who is using file device classes or expensive backend > deduplication (like Data Domain or Protectier) should seriously > consider switching to container pools. We are working on a design > for our next TSM servers and we are able to lower our costs per TB > by 75% compared to the old design based on the Data Domain! > > Kind regards, > > Eric van Loon > > Air France/KLM Storage Engineering > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On > Behalf Of Stefan Folkerts > > Sent: dinsdag 16 augustus 2016 8:33 > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: deleing data from a containerpool > > > > Yes, I too have noticed this and it is something to keep in mind. > > At the same time, I think almost everybody using this pool will be > using SSD's for the database the impact will be overseeable. > > But the directory containerpool is still the best thing to happen to > Spectrum Protect since replication came along if you ask me. great > performance increase over fileclass restores, no more stopping > reclaims during the day to increase restore performance, no more > messing with numopenvolsallowed and reclaim values and number of > processes to optimize daily operations and restore speed...oh, and > compression that saves an easy 30-50% storage and license cost on > top of the deduplication! > > > > > > > > > > On Mon, Aug 15, 2016 at 11:20 AM, Loon, Eric van (ITOPT3) - KLM < > eric-van.l...@klm.com> wrote: > > > > > Hi all! > > > After doing some extensive testing with a directory container > > > storagepool I noticed a significant change compared to the old > > > traditional storage pools. > > > In a traditional storage pool TSM stores a file like an object. In > > > most cases one file is one object as far as I could see. Deleting this > > > data is very fast: a delete filespace runs rather fast because TSM > > > only has to delete the objects. So deleting a large database client > > > with multiple TBs takes a few seconds or maybe a few minutes. > > > When you are using a container storage pool everything changes. Files > > > are still stored as objects, but objects are split into chunks. The > > > average size of a chuck is approx. 100 KB and TSM performs dedup on > > > this chuck level. So if you now delete a large file, TSM has to > > > inspect every chunk to see if it is unique or not. When it is unique > > > it will be deleted, otherwise not. If you delete a file which is for > > > instance 40 GB in size, TSM has to inspect around 420,000 chucks > > > before the object can be deleted. I noticed that this takes several > > > seconds to complete, so one has to take into consideration that the > > > deletion of large clients requires significant more time to > complete than one is used to. > > > Deleing a client with little more than 1 TB of Oracle data was running > > > for more than 20 minutes. So a delete filespace for really large > > > database clients can run for hours! Has anyone else noticed this > behavior too? > > > Kind regards, > > > Eric van Loon > > > Air France/KLM Storage Engineering > > > ******************************************************** > > > For information, services and offers, please visit our web site: > > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__www.klm.com&d=AwIGaQ&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=dOGCMY197NTNH1k_wcsrWS3_fxedKW4rpKJ8cHCD2L8&m=vUuUnchIk8qp8ANX9ecD5HSZje8iCRgiNUPhmahQWTQ&s=eE7XROkp9Iv02y6CJDM84muZgTbKNhpt7nAgYPrCs-0&e= > . This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee only. > > > If you are not the addressee, you are notified that no part of the > > > e-mail or any attachment may be disclosed, copied or distributed, and > > > that any other action related to this e-mail or attachment is strictly > > > prohibited, and may be unlawful. If you have received this e-mail by > > > error, please notify the sender immediately by return e-mail, and > delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > > > its employees shall not be liable for the incorrect or incomplete > > > transmission of this e-mail or any attachments, nor responsible > for any delay in receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch > > > Airlines) is registered in Amstelveen, The Netherlands, with > > > registered number 33014286 > > > ******************************************************** > > > > > ******************************************************** > > For information, services and offers, please visit our web site: > https://urldefense.proofpoint.com/v2/url? > u=http-3A__www.klm.com&d=AwIGaQ&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=dOGCMY197NTNH1k_wcsrWS3_fxedKW4rpKJ8cHCD2L8&m=vUuUnchIk8qp8ANX9ecD5HSZje8iCRgiNUPhmahQWTQ&s=eE7XROkp9Iv02y6CJDM84muZgTbKNhpt7nAgYPrCs-0&e= > . This e-mail and any attachment may contain confidential and > privileged material intended for the addressee only. If you are not > the addressee, you are notified that no part of the e-mail or any > attachment may be disclosed, copied or distributed, and that any > other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and > delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ > or its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > ******************************************************** > > > > ******************************************************** > For information, services and offers, please visit our web site: > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.klm.com&d=AwIGaQ&c=SgMrq23dbjbGX6e0ZsSHgEZX6A4IAf1SO3AJ2bNrHlk&r=dOGCMY197NTNH1k_wcsrWS3_fxedKW4rpKJ8cHCD2L8&m=_RJobktZCB7zYZCoquf3jomn8Nlbi-aGVQ85RnKoIgk&s=qEgmWsTrZupu_NgI3Yv44a1XXiTA_54QtdzaZ-z1Sow&e= > . This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part of > the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ > or its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ******************************************************** >