--
Emanuele Lombardi
mail: AMB-GEM-CLIM ENEA Casaccia
I-00060 S.M. di Galeria (RM) ITALY
mailto:lele_at_mantegna.casaccia.enea.it
tel +39 6 30483366 fax +39 6 30483591
This transmission was made possible by 100% recycled electrons.
> -----Original Message-----
>
> Dear alphists,
>
> I need your help about TZ885 DLT minilibrary
>
> Tz885 it is claimed to be 100/200 Gb capable, but I only
> succed in writing
> 20 Gb on each of its 5 CompacTape IV cartridge
> (BTW at least one DEC product was already named Compac
> several years ago!!!)
>
> In the front panel of TK885 I set the density to 20C wich is the
> maximum available BUT vdumps (both both with and without -C
> flag) reach
> the EOT after dumping more or less 20 Gb !!
>
> In the Tz885 user guide It is written that 20C means 20 Gb compressed
> while the density 20 (without C) means 20 Gb.
>
> The question is which is the difference among densities 20C and 20 ?
>
> I've planned to put 40 Gb on each cartridge (reaching the 200 Gb
> capapility), but now I discover that I can only have half of such
> space!!
>
> Any help will be apreciated!!
>
--------------------------------------------------------------------------------------------------
alan_at_nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.)
The native capacity of the TZ88 using a CompacTape IV is 20 GB. The
also supports the ability to compress data. For typical data, this
is usually around 2:1, giving a claimed capacity of 40 GB. However,
how much data will compress depends on the data. Data with very
regular, repeating patterns may compress more than 2:1. Data without
regular patterns may not compress at all and in some circumstances
may get larger. Data which is already compressed is a good example
of this. Newer drives detect when the data gets larger and simply
writes the original, but I don't think the TZ88 had that feature.
Since you're using Digital UNIX, I believe your choice of special
device when using the tape overrides the density selection used
on the front panel. So, while the drive is writing you may want
to check the claimed density.
Estimating how much data will compress is hard. If you have a
lot of files that are already compressed, you can expect that
software compression (-C) or drive compression won't help any
more. GIF, JPEG and MPEG are compressed formats for example.
Files which are sparse or contain large areas of NULs will
compress well.
You can get a rough idea of the amount of compression you're
likely to see by piping the output of vdump to the compress
program. Using the -v option on compression will give you
the percentage compression:
# vdump 0f - /file-system | compress -v > /dev/null
The capacity of the tape isn't precisely 20,000,000,000 bytes
of course. Some media errors are filtered by the drive by
simply skipping over the bad block, wasting that space. The
drive may write a padding block in order to keep the drive
streaming if there isn't sufficient data. The backup format
itself uses some tape data for file information. If you have
a lot of small files, you could have nearly as much file meta-
data on the tape as file data. Again, having vdump write to
a pipe can be informative:
# vdump 0f - /file-system | wc -c
Compare the amount of data you expected to read, with the
amount of data written. The difference is the overhead of
the backup command.
----------------------------------------------------------------------------------------------
mbertone_at_gtech.com (Mitch Bertone)
Your tapes might have be initialized on an TZ88 drive at one time at
20 Gig, and the format at which they are initialized will be picked up
and used again by the tape drive.
Insert a CompacTape IV in the drive and press the Density Override
button until the lights for 20.0 and Compress are light, then mount
and dump anything to the tape ( doesn't matter what) do this for
all your tapes. The next time the drive sees this same tape, it should
automatically select 20.0 and Compress, and you should be able to get
40 gigs on one tape, just remember to do this for all your tapes as
you cycle through them. You will only have to do the density override
once !!
---------------------------------------------------------------------------------------------------
"Monjar, Daniel" <Monjar_at_orgtek.com>
Like any compression scenario it all depends on what you are compressing.
The 2x compression is an average over different file types. I always plan
on the uncompressed capacity and then allow myself to be pleasantly
surprised by how much more I'm getting. Planning on the 2x compression rate
leaves you open for some unpleasant surprises.
---------------------------------------------------------------------------------------------------
aoki_at_CS.Berkeley.EDU (Paul M. Aoki)
you understand correctly, and if it says "20C" *while you're dumping*
(as opposed to before it starts writing data) then it sounds like
you're doing everything right.
in that case, the mostly likely explanation (without knowing anything
else) is that your data is either already compressed or has very low
entropy (in the information theory sense). the DLT uses essentially
the same algorithm, LZ compression, as unix compress and gnu zip. if
your data is already (mostly) compressed, you will see no benefit from
hardware compression. in fact, well-compressed data will *expand*
slightly. certain other common forms of uncompressed data (random
numbers, encrypted data, binary floating point data with so little
correlation that it looks essentially random) will not compress much,
either.
iirc (a big if), you may also have to watch out because the DLTs
normally autosense the density. if i *set* the DLT at the front panel
to "20C" then it will use "20C" and override autosense; if i tell it
to *default* to "20C" (using a /dev that specifies that density) and
the tape was previously written as "20" then it will use the previous
density/compression. you can see if this is the case by watching the
display as it writes the tape. (i could be remembering part of this
wrong, but at least it gives you something to look for.)
note that many people choose to use the uncompressed format because
using the hardware compression makes it impossible to predict how much
will fit on a tape! by contrast, if you compress the data using
software and then blast it to tape (e.g., using the amanda backup
system) then you can manage this problem a bit more robustly.
Received on Fri Nov 20 1998 - 11:18:36 NZDT
This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT