The client is 7.1 but our servers are still at 6.3. Also I had to switch to a storage server that does not have dedup on it as that slows the WAN transfer way down (I only get about 20% network utilization when data is being deduped, regardless of the RESOURCEUTILIZATION setting). I am also noticing "Retry 1" and "Retry 2" so maybe the data is being sent three times over the wire for these files? With many compression schemes a file that is already compressed only grows a very small amount when you compress it so I don't see the purpose of resending it twice over the wire. I will try the compressalways yes setting but hopefully that won't override the exclusions I have set up for common compressed files.
On Thu, Jun 30, 2016 at 9:17 AM, Paul Zarnowski <p...@cornell.edu> wrote: > You can specify 'compressalways yes', which will prevent the retry. > However, you then have to live with the fact that the file is expanded in > TSM storage. > > I believe this problem does not apply to LZ4 compression, introduced with > the latest clients when backing up to a container pool and using dedup. > > At 08:57 AM 6/30/2016, you wrote: > >I have been watching an initial TSM backup running for a long time now > over > >a WAN connection (100mbit/sec) and I keep seeing "compressed data grew" > >followed by a "Retry". Does this mean that for every file that > >compression increased the size (even 1%) the whole transfer is discarded > >and it starts over again with the same file (presumably with compression > >disabled)? If so that is probably hurting my backup speed much more than > >the compression ever improved it. Is there any way to prevent this short > >of adding one of these options for every type of compressible file? > > > >EXCLUDE.COMPRESSION "*:\...\*.jpg" > >EXCLUDE.COMPRESSION "*:\...\*.zip" > > > -- > Paul Zarnowski Ph: 607-255-4757 > Assistant Director for Storage Services Fx: 607-255-8521 > IT at Cornell / Infrastructure Em: p...@cornell.edu > 719 Rhodes Hall, Ithaca, NY 14853-3801 >
