Questions bru-ing in my mind

[Fred Fish]

In article <1990Dec24.155048.29640 at cunixf.cc.columbia.edu> shenkin at cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
>It seems that there would be no problem in making size correspond to
>the size of the recommended tape -- if the actual tape were shorter, 
>then presumably the end-of-tape signal would over-ride it, no?

The problem here is that many drivers provide no way to distinguish between
bumping into the end of the tape and hitting a hard error that one
cannot advance past.  Bru assumes that any unrecoverable read or write
error indicates end of tape unless the "advance" flag is set.

	size=	advance		Action

	0	not set		Assume an infinite length tape, any
				hard error means end of tape.

	>0	not set		Assume that the tape is the specified
				size.  Any hard error before reaching
				that size may be either eot or a real
				error.  Issue warning and switch to next
				media.

	0	set		Assume an infinite length tape, any
				hard error is either eot or real error.
				Do NOT issue warning, switch to next media.

	>0	set		Assume that the tape is the specified
				size.  Any hard error before reaching
				that size is a tape error that can be
				advanced past by continuing to read or
				write.  Do this until we get to the
				given size.

Note that the last case is the killer if your drive does NOT advance and
you have advance set.  Bru will continue trying to read or write for 
however long it takes to get to where it thinks the end of media should be.
Most 1/4" tapes go belly up at the first read/write error and refuse to
have anything further to do with that tape.

>Now, a naive question.  If I do want to edit /etc/brutab, how do I
>figure out how to set the size?  For instance, I have a DC 6150 which is
>620 Ft. in length, and that also says 12,500 FTPI on it.  What is the size?

The simpliest way is to leave the brutab size parameter at 0K, and write
enough data with the -v option to fill up a tape.  Notice the running
size total and subtract off about 5-10% for a "fudge factor".  Use this
size in your brutab entry.

Another way is "dd if=<some very large file> of=/dev/rmt/tp ibs=1k obs=1k"
and see how many blocks it takes for dd to bump into the end of the media.

>But if I could do this, I could do something like
>	bru -evZ / >& tmpfile
>at the beginning of my backup day.  It would take a few hours to run,
>but then I could feed tmpfile into an awk script or other simple program which
>would divvy the files up into single-volume-sized groups, and then I could
>bru the groups one by one.  It would seem simpler to allow than to disallow
>this, so why prevent this use?

You can do this with "bru -cvZf /dev/null / >tmpfile".  Internally, the
-e option is almost identical to the -c option, except that no I/O buffers
are built or written.