ADSM-L

Re: [ADSM-L] ULTRIUM4C but not 1.6TB

2010-12-13 20:38:45
Subject: Re: [ADSM-L] ULTRIUM4C but not 1.6TB
From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 14 Dec 2010 01:37:30 +0000
Ok, I finally found this statement in SG24-6946, which is an old book.  Can't 
find anything that explains how it achieves the result:

"The 3592 Model J1A Tape Drive has ..... (snip)
It uses an optimal dynamic compression method called byte level compression 
scheme
swapping, which is designed to achieve maximum data compression, and unlike
other tape drive compression methods, it is designed to prevent data expansion."



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Richard Sims
Sent: Thursday, December 09, 2010 1:36 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] ULTRIUM4C but not 1.6TB

On Dec 9, 2010, at 12:26 PM, Scott McCambly wrote:

> ...
> 
> I always assumed that the hardware compression mechanism would have
> something equivalent to "CompressAlways=NO" and detect already
> compressed data in its input buffer, however we backup a number of
> already compressed file formats and often see FULL tapes with estimated
> capacities from 5 to 20% less than the stated native (uncompressed)
> capacity.

Technote 1267820 at least contributes to explaining this, where the effects are 
familiar to old MVS programmers using Fixed Block processing and dealing with 
short blocks.  In this context, consider the impact that in-Aggregate 
reclamation will contribute.

   Richard Sims   http://people.bu.edu/rbs