[ On Fri, September 18, 1998 at 17:30:08 (+0000), Brian Buhrow wrote: ]
> Subject: Re: problems with Exabyte 8200 on NetBSD/sparc 1.3.1
>
> 	Well, I've been using an Exabyte 8200 on NetBSD for years.  This is
> under I386, but I think the drivers are similar enough that you shouldn't
> have a problem.  Right now I'm backing up 1.2G on my system every week with
> room to spare on the tape.  For what it's worth, here's a script of what
> parameters I'm using. It's also worth noting that we use these parameters
> un SunOS connected Exabyte 8200 machines as well at work where they perform
> the same as they do on NetBSD.  I think the dey is the density and block
> size.  The default block size lets the 8MM tapes waste a lot of space.  The
> larger block size keeps the tape streaming and the blocks full.  I wonder
> if you convert to these params if you  have the same trouble?

Actually it streams along quite well with just '-b 1'.  The activity
light stays on pretty steady on the drive.  Dump reports about 120 KB/s,
which is what I see comming off the disk too (with vmstat, etc.).  If I
had two separate SCSI controllers I'd expect about twice that, but this
is OK for now.

Now if only dump worked.  Nothing in the diff between 1.3.1 and -current
seems as if it could be related to this "master/slave protocol botched"
problem.  The biggest change seems to be what's needed to try and handle
byte-swapped filesystems.  I'm not too enthusiastic about re-compiling
it and starting another three hour test, though at this point I could go
watch TV and forget about it until morning!  ;-)

Damn.  The -current dump won't compile easily on 1.3.1.

Perhaps this is indeed a NetBSD/sparc specific bug, though indeed I
don't know of anyone who's actually tried a multi-tape dump recently
with any kind of NetBSD system.  I used the '-B 2200000' value to try
and make the best of the tape, but according to the drive's SCSI errors
it ran out of tape before it got that far (which is rather confusing).
I used the '-B 2200000' value to try and make the best of the tape, but
according to the drive's SCSI errors it ran out of tape before it got
that far (which is rather confusing).  Perhaps if I try a smaller number
and make dump ask for a new tape before it gets an end-of-media error
I'll avoid this bug....  However even if I say '-B 2000000' it still
says "DUMP: estimated 1955773 tape blocks on 0.98 tape(s)".

This time I started it with '-b 64' too, and that seems to have
significantly improved the throughput.  It's reading as much as 240 KBps
from the disk now (though averaging probably 225 KBps)!

Does anyone know the physical recording format for Exabyte 8200?  Is it
possible that because I specified too small a tape record (i.e. -b 1)
that the inter-record gaps were eating up valuable tape space, just as
what happens on 9-track tape?

Maybe I'll get lucky and it'll all fit on one tape and I can forget
about this silly "protocol botched" error.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>