I dind't want to pull you into that Arnaud, I was just interested in the
performance test results, that's all.
I hope it's gets worked out and the performance improves, good luck.


On Thu, Apr 12, 2018 at 5:15 PM, PAC Brion Arnaud <
Arnaud.Brion AT panalpina DOT com> wrote:

> Stefan,
>
> I do not want to enter the details of a 6 months lasting story, but to
> summarize it, such performance tests have been successfully conducted
> against our very first setup, which in between time has been subject to
> countless changes (TSM version, O.S. version, endianness from Big to Little
> endian, extension of the FS900 capacity, redesign of the storage pools
> layout and so on), the whole under huge time pressure, having the result
> that the current setup could not be benchmarked anymore, as it was already
> productive ...
>
> Cheers.
>
> Arnaud
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Stefan Folkerts
> Sent: Thursday, April 12, 2018 2:10 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: disabling compression and/or deduplication for a client
> backing up against deduped/compressed directory-based storage pool
>
> I understand, I didn't know you were that deep into the case already, I
> wouldn't presume to be able to solve this via a few emails if support is
> working on it.
>
> What I am interested in is did you run the blueprint benchmarks? the perl
> script that can benchmark your database and your containerpool volumes?
> The blueprints give values that you should be getting in order to expect
> blueprint performance results, this way you can quantify your performance
> issue in how many IOP/s or MB/s your behind where you need to be to run the
> load you need to run.
>
> Regards,
>     Stefan
>
>
>
>
> On Wed, Apr 11, 2018 at 2:10 PM, PAC Brion Arnaud <
> Arnaud.Brion AT panalpina DOT com> wrote:
>
> > Dear Stefan,
> >
> > Thanks a lot for your very kind offer !
> >
> > Without underrating the power of this list, I however doubt that we will
> > able to find a solution that easily : we opened a case with IBM and
> > involved EMC/Dell as well, so far without much success, even after 5
> months
> > intensive monitoring and tuning attempts at all levels (Linux kernel,
> > communication layer, TSM DB fixes, access mode change on Isilon etc ...)
> >
> > I must share as well that some of our partners voices raised when the
> > decision had been made to go with Isilon storage, warning us that the
> > offered solution would not be powerful enough to sustain the intended
> > workload. It might very well be that they were right, and that in this
> > particular case, budget considerations have ruled over pragmatism,
> leading
> > to that very uncomfortable situation ...
> >
> > To finally answer your question : both active log and database are stored
> > on a Flashsytem 900 array, dedicated to TSM server only.
> >
> > Cheers.
> >
> > Arnaud
> >
> > ************************************************************
> > ********************************************************************
> > Backup and Recovery Systems Administrator
> > Panalpina Management Ltd., Basle, Switzerland,
> > CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
> > Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
> > Direct: +41 (61) 226 19 78
> > e-mail: arnaud.brion AT panalpina DOT com
> > This electronic message transmission contains information from Panalpina
> > and is confidential or privileged.
> > This information is intended only for the person (s) named above. If you
> > are not the intended recipient, any disclosure, copying, distribution or
> > use or any other action based on the contents of this
> >  information is strictly prohibited.
> >
> > If you receive this electronic transmission in error, please notify the
> > sender by e-mail, telephone or fax at the numbers listed above. Thank
> you.
> > ************************************************************
> > ********************************************************************
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > Behalf Of
> > Stefan Folkerts
> > Sent: Wednesday, April 11, 2018 7:43 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: disabling compression and/or deduplication for a client
> > backing up against deduped/compressed directory-based storage pool
> >
> > That's no fun, maybe we can help!
> > What storage are you using for your active log and database?
> >
> > Regards,
> >    Stefan
> >
> > On Mon, Apr 9, 2018 at 6:06 PM, PAC Brion Arnaud <
> > Arnaud.Brion AT panalpina DOT com
> > > wrote:
> >
> > > Hi Stefan,
> > >
> > > Thanks a lot for appreciated feedback !
> > >
> > > >> You can, however, disable compression on the storagepool-level.
> > >
> > > This is unfortunately what I intended to avoid : if I disable it, then
> > > lots of clients will be impacted, and the server's performance will for
> > > sure improve ...
> > >
> > > >> Are you using an IBM blueprint configuration for the Spectrum
> Protect
> > >
> > > I wish I could : my life would have been much easier ! Unfortunately
> > > management took the (definitively bad) decision to invest in a EMC/Dell
> > > Isilon array to be our Spectrum Scale server storage.
> > > I'm now fighting since 6 months to have the whole working together, so
> > far
> > > without real success : performance is horrible  :-(
> > >
> > > Cheers.
> > >
> > > Arnaud
> > >
> > >
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > > Behalf
> Of
> > > Stefan Folkerts
> > > Sent: Thursday, April 05, 2018 5:48 PM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: Re: disabling compression and/or deduplication for a client
> > > backing up against deduped/compressed directory-based storage pool
> > >
> > > Hi,
> > >
> > > With the directory containerpool you cannot, for as far as I know,
> > disable
> > > an attempt to deduplicate the data and if the data is able to
> deduplicate
> > > it will be deduplicated.
> > > You can, however, disable compression on the storagepool-level. If you
> > > disable it on the containerpool client-side settings for deduplication
> > will
> > > have no effect on compression within the pool.
> > >
> > > Are you using an IBM blueprint configuration for the Spectrum Protect
> > > environment?
> > >
> > > Regards,
> > >    Stefan
> > >
> > >
> > > On Tue, Apr 3, 2018 at 6:06 PM, PAC Brion Arnaud <
> > > Arnaud.Brion AT panalpina DOT com
> > > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Following to global client backup performance issues on some new TSM
> > > > server, which I suspect to be related to the workload induced on TSM
> > > > instance by deduplication/compression operations, I would like to do
> > some
> > > > testing with a client, selectively disabling compression or
> > > deduplication,
> > > > possibly both of them on it.
> > > >
> > > > However, the TSM server has been configured to only make use of
> > > > directory-based storage pools, which have been defined having
> > > deduplication
> > > > and compression enabled.
> > > >
> > > > Thus my question : is there any mean to configure a client, so that
> its
> > > > data  will not be compressed or deduplicated ?
> > > >
> > > > From my understanding, setting up "compression no" in the client
> option
> > > > file will be of no use, as the server will still be compressing the
> > data
> > > at
> > > > storage pool level.
> > > > Likewise, setting up "deduplication no" in the client option file
> will
> > > > refrain the client to proceed to deduplication, but the server still
> > > will.
> > > > The last remaining possibility  that I can think of, to disable
> > > > deduplication, would be to make use of some "exclude.dedup" statement
> > on
> > > > client side, that would exclude anything subject to backup.
> > > >
> > > > What are your thoughts ? Am I condemned to define new storage pools
> not
> > > > enabled for deduplication and or compression to do such testing, or
> is
> > > > there some other mean ?
> > > >
> > > > Thanks a lot for appreciated feedback !
> > > >
> > > > Cheers.
> > > >
> > > > Arnaud
> > > >
> > > > ************************************************************
> > > > ********************************************************************
> > > > Backup and Recovery Systems Administrator
> > > > Panalpina Management Ltd., Basle, Switzerland,
> > > > CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
> > > > Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
> > > > Direct: +41 (61) 226 19 78
> > > > e-mail: arnaud.brion AT panalpina DOT com<mailto:arnaud.brion AT 
> > > > panalpina DOT com
> >
> > > > This electronic message transmission contains information from
> > Panalpina
> > > > and is confidential or privileged.
> > > > This information is intended only for the person (s) named above. If
> > you
> > > > are not the intended recipient, any disclosure, copying, distribution
> > or
> > > > use or any other action based on the contents of this
> > > > information is strictly prohibited.
> > > >
> > > > If you receive this electronic transmission in error, please notify
> the
> > > > sender by e-mail, telephone or fax at the numbers listed above. Thank
> > > you.
> > > > ************************************************************
> > > > ********************************************************************
> > > >
> > >
> >
>