On Thu, 25 Aug 2005, Geert Hendrickx wrote:

> On Sat, Aug 06, 2005 at 03:23:37PM +0200, Geert Hendrickx wrote:

> > One solution would be to embed gzip into dump(8) (and gunzip into
> > restore(8)), so dump can start a new volume when the *compressed* data
> > has reached a predefined size.  Or, more generally, we could define an
> > extra command line option for dump so that it accepts a command
> > (sequence) through which it pipes all the data before writing it to
> > tape/file.  Then the user can pipe it through anything he wants, be it
> > gzip, gnupg, ...  Same for restore, of course.

Of course, stream compression assumes zero corruption on the tape, which
becomes more probable as the tape dump gets larger.  Once a corrupted block
is hit, the rest of the dump is unusable (or at least, a pretty huge chunk;
things like bzip2recover can reset the decompression every once in a while
in the data stream).

> It would be very nice if NetBSD's dump would support compressed output too.

...if the compression were on a per-file basis, not a whole-dump basis, so
that the risk of middle-of-dump corruption is minimized.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>