8mm Backup strangeness

[Clint Greene]

In article <9009042005.AA28494 at remote.dccs.upenn.edu> YATES at C.CHEM.UPENN.EDU ("Yates, John H.") writes:
>I am finding Backup strangeness on 8mm Backup's. The following script should
>use Backup for /usr /u0 /u1, ... /u7 , rewind the tape and List_tape them all.
>I am glad I did this sanity check because some marbles (filesystems) are
>missing. (skip the sleep's, I don't think they are necessary and are only
>there as a desperate guess).
>What happens is, all of the Backups appear to work, but after rewinding
>and doing a List_tape, only the 3rd, 6th, and 9th sets appear.
>
>Some sort of header, trailer, tapemark problems with putting multiple Backup's
>on one 8mm tape? Anyone know what gives?
>
>Thanks, John
>yates at c.chem.upenn.edu
>

Script and messages deleted

If you look at the List_tape script in /usr/sbin you'll see that
it is calling bru with the -g option just to verify that the tape 
is truly in bru format. The problem arises from the fact that you
are using the no-rewind device, so after the bru -g, the tape is 
positioned after teh first block and then they do another bru -g
to list the header and then a bru -t get the file contents. Well
the bru -g will cough/choke/die on the second issuance because
bru itself verifies whether or not the tape is bru format. That is
probably why you only see the 3rd, 6th and 9th set of files, while
your script says it is the 1st, 2nd and 3rd.

If you were to just run bru -tvvvv on this tape 9 times using the 
no-rewind (tps0d6nr) device you would find all your data there.

The problem is not an exabyte or any other tape drive problem. It is
a List_tape problem. I filed a bug on it a while back, but I don't
know how they will fix it. It really isn't made to handle multiple
archive tapes. The 3.3 version has the same problems.

Now tar and exabyte under 3.2 did have problems with multiarchive
backups. There was a bug in the driver that would not aloow tar to
read any archives past the first one on the 8mm tape drive. Tar would
appear to write the multiple archives, but would only list the first
archives contents, but when asked to read the 2nd or subsequent 
archives it wold appear to hang when in reality it is reading the tape
and runs to the EOT where it gives a read error, but you have to wait
a few minutes for it to get there. This I believe is fixed in 3.3 and 
possibly in 3.2.3. Dave Olson maybe to answer that with some authority.