ADSM-L

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

2016-08-22 16:53:58
Subject: Re: [ADSM-L] deleing data from a containerpool
From: Matthew McGeary <Matthew.McGeary AT POTASHCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 22 Aug 2016 14:50:51 -0600
I bled hard and installed 7.1.5 while the paint was wet.

Compression was available on AIX concurrently with all other releases.  WAN acceleration, on the other hand, is not.  Booo!
__________________________

Matthew McGeary
Senior Technical Specialist - Infrastructure
PotashCorp
T: (306) 933-8921
www.potashcorp.com





From:        David Ehresman <david.ehresman AT LOUISVILLE DOT EDU>
To:        ADSM-L AT VM.MARIST DOT EDU
Date:        08/22/2016 08:16 AM
Subject:        Re: [ADSM-L] 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>