• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Confusion over compressalways option?

ldmwndletsm

ADSM.ORG Member
Joined
Oct 30, 2019
Messages
163
Reaction score
1
Points
0
Can someone confirm the IBM documentation?

https://www.ibm.com/support/knowled...tsm.perf.doc/r_opt_client_compressalways.html

The second paragraph where it says: "To reduce the impact of repeated compression attempts if the compressed file is larger than the original, specify compressalways yes. "

Don't they mean 'no'? The following IBM document suggests to me that it should be 'no': https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.0/client/r_opt_compressalways.html

Is that a typo?

I thought I'd read somewhere else too wherein the documentation reads 'yes', and I would think it would be 'no', but I can't find it now. Will post if I can locate it. Thanks.
 

Trident

TSM/Storge dude
ADSM.ORG Moderator
Joined
Apr 2, 2007
Messages
526
Reaction score
58
Points
0
Location
Oslo, Norway
Website
www.basefarm.no
Hi,

I do not have the answer based on doc's, but I can write something about it. The file is checked for compressability. I am not sure how much of the file is read before a conclusion is made. It can be 1 MByte, or 5% of the file or something else. IBM should be able to provide a technical answer there.

There are a few different scenarios to evaluate.

  1. File begins with a non-compressible data, rest is highly compressible
  2. File begins with a highly compressible part, rest is not compressible
  3. File is not compressible
  4. All file is compressible
To get the most out of your storage, configure as below.

  1. This could trick SP to skip compression since the first part does not compress. This is where Compression yes, compressalways yes should be used. Or include.compresion.
  2. Exclude compression for filetype/directory. You will otherwise waste cpu to save nothing. Exclude.compression.
  3. Exclude. compression
  4. Include.compression
To get the most out of this, you need to know your clients data types. Works well with small systems, but for 1000's of nodes, you could end up with micro management.

If you have enabled dedup, then there is a new set to look at. Each file is split into chunks, and each of these are evaluated. Probably as above.
 

marclant

ADSM.ORG Moderator
Joined
Jun 16, 2006
Messages
3,602
Reaction score
578
Points
0
Location
Canada
Website
www-947.ibm.com
The second paragraph where it says: "To reduce the impact of repeated compression attempts if the compressed file is larger than the original, specify compressalways yes. "
That statement is correct. With compressalways yes, it will send them compressed all the time, so there's no repeated attempts to compress, then resend uncompressed if larger. With compressalways no, the client will attempt to compress files, and if they grow bigger it will send the file uncompressed instead.
 

ldmwndletsm

ADSM.ORG Member
Joined
Oct 30, 2019
Messages
163
Reaction score
1
Points
0
So if this is set to 'no' then how many times does it attempt to compress before it realizes it's a failed venture? If it compresses it, and the result is larger, why would it reattempt it?
 

Trident

TSM/Storge dude
ADSM.ORG Moderator
Joined
Apr 2, 2007
Messages
526
Reaction score
58
Points
0
Location
Oslo, Norway
Website
www.basefarm.no
Hi,
I think it will only try once. If file grows during compression, ie reading a non-compressable file, it will stop and start again sending all file data uncompressed.
 

marclant

ADSM.ORG Moderator
Joined
Jun 16, 2006
Messages
3,602
Reaction score
578
Points
0
Location
Canada
Website
www-947.ibm.com
So if this is set to 'no' then how many times does it attempt to compress before it realizes it's a failed venture? If it compresses it, and the result is larger, why would it reattempt it?
Once per file, the repeat comes from processing thousands of files during a backup. And also day after day when rebacking up those same files as they change.
 

ldmwndletsm

ADSM.ORG Member
Joined
Oct 30, 2019
Messages
163
Reaction score
1
Points
0
Once per file, the repeat comes from processing thousands of files during a backup. And also day after day when rebacking up those same files as they change.
I must be missing something major here. If compression is enabled, and TSM decides that a file needs to be backed up then why would this burden not also occur with the compressalways option set to yes? If it's set to yes then it must compress it, and it must send the result regardless of the compressed size; otherwise, if set to no, then it must also compress since that's the only way it will know if it's smaller than the uncompressed version. Now, whether it then sends it uncompressed or not obviously depends on the results. But regardless of the setting, compression will be attempted. I fail to see how either setting is different in terms of the work load on the client other than the fact that if it's set to no then it must do a subsequent size compare. All those milliseconds for those compares might add up. Is that what you're saying?

Otherwise, the only thing I could possibly see (or imagine) is that perhaps TSM keeps track of the setting (yes or no) for each backed up file?, and if it sees that the file was sent uncompressed the last time, when this option was set to no, then if this is still set to no then it won't bother to retry to compress it again the next time it backs it up, so it will just send it uncompressed, thus saving time? Otherwise, if it was sent compressed the last time, when it was set to yes, then it sends it compressed again. But if any of this is the case then it would seem that having it set to no would be more efficient. All of this seems unlikely to me based on what I read in the documentation, but then again, I haven't always found the documentation clear on a number of points.
 

marclant

ADSM.ORG Moderator
Joined
Jun 16, 2006
Messages
3,602
Reaction score
578
Points
0
Location
Canada
Website
www-947.ibm.com
All those milliseconds for those compares might add up. Is that what you're saying?
Essentially, yes. And if the files are large, it will take more than a few milliseconds to compress it to determine if it grew or not.

Otherwise, the only thing I could possibly see (or imagine) is that perhaps TSM keeps track of the setting (yes or no) for each backed up file?
No.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 18 18.4%
  • Keep using TSM for Spectrum Protect.

    Votes: 60 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 12 12.2%
  • Other (please comement)

    Votes: 8 8.2%

Forum statistics

Threads
31,738
Messages
135,308
Members
21,740
Latest member
mjkoz
Top