SUMMARY: High Compression vs standard

Date: Tue Nov 24 1998 - 14:10:49 CST

The general feeling of the responses was that the DLT tape drives
incorporate maximum compression by default, thus the reason I am getting
120-125GB on a 20/40 Gb DLT tape. I'm only getting 21-23 GB per Unix File
System DLT tape though becaues apparently the information isn't very
compressible. One suggestion was to possibly 'fool' the application into
using the high compression by making that the standard '/dev/rmt/0' device,
though now I don't that would work because we're getting maximum
compression as it is. Any software-based compression (it seems from the
responses) would not be worth the time it would take. It could
significantly increase the backup time and only slightly (if at all)
increase the compression.

And to answer the other question as to data integrity: The one response I
received concerning this was that there should be no issues regarding data
integrity if the higher compression (h instead of m) is used.

Many thanks to the following people who responded (Hope I didn't miss

Greg Sawicki <> (Kelly Fergason) (Brett Lymn)

Rachel Polanskis <>



Our current Legato Networker setup references our DLT drives as
      /dev/rmt/1mbn and /dev/rmt/2mbn. Since we are using DLT IV type
      tapes, (20/40 Gb) would I gain any added compression by using
      /dev/rmt/1hbn and /dev/rmt/2hbn respectively? Does it matter if it
      is a single or jukebox DLT drive? The reason I am asking is that we
      are storing approximately 120-125GB per tape on the tapes in the
      jukebox that are Database backups, but the Unix file system back
      tapes in the same jukebox only store about 22-23 Gb. I was hoping to
      get more compression on the Unix side. If it is possible to use
      "hbn" for higher compression, are there any risks involved in data

Thanks for any ideas! Will summarize immediately.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:53 CDT