Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!cs.utexas.edu!asuvax!mcdphx!riscokid.UUCP!fnf From: fnf@riscokid.UUCP (Fred Fish) Newsgroups: comp.sys.sgi Subject: Re: Questions bru-ing in my mind Message-ID: <14373@mcdphx.phx.mcd.mot.com> Date: 10 Jan 91 14:29:39 GMT References: <1990Dec18.211216.24299@cunixf.cc.columbia.edu> <1990Dec21.174239.11753@odin.corp.sgi.com> <1990Dec24.155048.29640@cunixf.cc.columbia.edu> Sender: listen@mcdphx.phx.mcd.mot.com Reply-To: fnf@riscokid.UUCP (Fred Fish) Organization: Motorola Microcomputer Division, Tempe, Az. Lines: 61 In article <1990Dec24.155048.29640@cunixf.cc.columbia.edu> shenkin@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= 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.