Amanda-Users

Re: Tape DDS-3 values

2002-09-13 10:50:22
Subject: Re: Tape DDS-3 values
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users AT amanda DOT org
Date: Fri, 13 Sep 2002 10:25:29 -0400
On Thu, Sep 12, 2002 at 08:36:26PM +0200, Brian Jonnes wrote:
> On Thu 12 Sep 02 16:38, Niall O Broin wrote:
> > This is true but as a friend pointed out to me recently when I was having
> > some tape reading problems - if you get some bit errors reading a tar file
> > from a tape, most likely asll you will lose is the affected file. If OTOH
> > you get bit errors reading a gzipped tar file, you most likely will not be
> > able to read anything after the bit errors. Just something to be aware of.
> 
> So... when, and how much work is it to get bzip2 used. Apparently it doesn't 
> suffer from this problem? 

When?  As soon as someone (you?) comes up with the appropriate changes (to
make it an either/or), tests them, and submits them.

> If I were to replace (by hook or by crook) the COMPRESS_PATH to bzip2 would 
> that work?

I scanned amanda-hackers and amanda-users archives on yahoo-groups for "bzip".
Among the relatively few hits I found one of my own replies (attached).  It
was musing about how one could "dropin" bzip2.

Caveats, I never tried it, no one ever replied they tried it, and my musing
was based on 2.4.2.  2.4.3 may have some different or new parameters.

> And what is the opinion of the Right Way to do this?

Some of the archive postings mentioned the "right way" was to finish the
design and implementation of the FILTER-API.  But I doubt that has progressed.

Is it a real, or theoretical, problem?  I.e. has anybody experienced bit errors
in a gzip'ed document?  For me the incidence is low enough that I don't feel a
need to use bzip2 for that extra protection.  The value of your data may lead
to a different conclusion.

I looked at bzip2 for its higher compression ability compared to gzip.  However
its slow execution on my systems made me lose interest.  I don't even use the
"--fast" option of gzip because of reduced performance.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

Attachment: bznote
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>