ADSM-L

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

2016-08-22 09:16:40
Subject: Re: [ADSM-L] deleing data from a containerpool
From: David Ehresman <david.ehresman AT LOUISVILLE DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 22 Aug 2016 13:12:09 +0000
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

********************************************************