ADSM-L

Re: [ADSM-L] deleing data from a containerpool

2016-08-22 11:47:22
Subject: Re: [ADSM-L] deleing data from a containerpool
From: Del Hoobler <hoobler AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 22 Aug 2016 11:44:38 -0400
To be clear...

Server-side inline compression shipped in 7.1.5 (March) however the 
"client-side" LZ4 compression piece of this shipped in 7.1.6 (June).


Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/22/2016 
10:11:08 AM:

> From: David Ehresman <david.ehresman AT LOUISVILLE DOT EDU>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 08/22/2016 10:12 AM
> Subject: Re: deleing data from a containerpool
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 
> 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 AT VM.MARIST DOT EDU] On 
> Behalf Of Del Hoobler
> Sent: Monday, August 22, 2016 10:02 AM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU> wrote on 08/22/2016 
> 
> 09:53:08 AM:
> 
> 
> 
> > From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> 
> > To: ADSM-L AT VM.MARIST DOT EDU
> 
> > Date: 08/22/2016 09:53 AM
> 
> > Subject: Re: deleing data from a containerpool
> 
> > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On 
> 
> > Behalf Of David Ehresman
> 
> > Sent: maandag 22 augustus 2016 15:12
> 
> > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On 
> 
> > Behalf Of Rhodes, Richard L.
> 
> > Sent: Monday, August 22, 2016 9:07 AM
> 
> > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On 
> 
> > Behalf Of Loon, Eric van (ITOPT3) - KLM
> 
> > 
> 
> > Sent: Tuesday, August 16, 2016 3:39 AM
> 
> > 
> 
> > To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On 
> 
> > Behalf Of Stefan Folkerts
> 
> > 
> 
> > Sent: dinsdag 16 augustus 2016 8:33
> 
> > 
> 
> > To: ADSM-L AT VM.MARIST DOT 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.Loon AT klm DOT 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
> 
> > ********************************************************
> 
> > 
> 
> 
> 
> 
> 


<Prev in Thread] Current Thread [Next in Thread>