Xref: utzoo comp.sys.amiga:66320 comp.sys.amiga.tech:14516
Path: utzoo!attcan!uunet!cs.utexas.edu!asuvax!mcdphx!riscokid.UUCP!fnf
From: fnf@riscokid.UUCP (Fred Fish)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: A3000 and WB2.0 --- HELP!!!
Keywords: a3000,wb2.0,ram,memory,bru
Message-ID: <13618@mcdphx.phx.mcd.mot.com>
Date: 18 Sep 90 14:41:28 GMT
References: <1788@nemesis.stsci.edu>
Sender: listen@mcdphx.phx.mcd.mot.com
Reply-To: fnf@riscokid.UUCP (Fred Fish)
Followup-To: comp.sys.amiga
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 39

In article <1788@nemesis.stsci.edu> scott@stsci.EDU (Jim Scott) writes:
> 2.     i have tried backing up my hard disk.  since the tool 
>       "hdbackup" is not available yet, c= has given 3000 owners
>       bru.  when i try to use the compress option (-z) i get
>       about 5 floppies into it and get a ram disk full error.
>       wierd.   it is writting to df0.  what has ram got to do 
>       it?  it does say in the manual, do not attempt the comp-
>       ression if you have <= 512k ram.  well, that shouldn't be
>       a problem!  bru _will_ do the whole backup perfectly
>       fine if i do not  compress (37 floppies! yikes!)

One of the "features" of the bru format is that it REALLY wants
to know how big the file is before it starts writing it out.  This is
so it can record the size in the file header block in the archive,
allowing it to seek to the next file header block when the archive
device is seekable (thus a "-t" on a floppy may only take 5-15 seconds
instead of about 90).  Since there is no way to know the size of the
compressed file without actually compressing it first, bru creates
a temporary copy in the place specified by the environment variable
BRUTMPDIR, usually pointing to "ram:".  For really large files, or
small amounts of ram, you have an obvious problem.  You can try
setting BRUTMPDIR somewhere else, like to a directory on the hard
disk.

Before anyone else beats me to it, I should point out that there
are a couple of things bru could do differently.  One is that it
could compress the file twice, first to find the compressed size,
and again to write it out.  This eliminates the temporary file, but
just about doubles the time requirements, and if the file happens
to change between each pass, the compressed size would likely be
different anyway.  Another thing it could do is to write the file
out to the archive, compressing it on the fly, and then seek back to
the header block to record the final size.  This would work ok for
seekable devices like floppies, but fails on things like streaming
tapes, pipes, or serial lines (the archive format is a pure stream
format which means that bru should never be required to "backup" in
the archive).

-Fred