Xref: utzoo comp.unix.wizards:6726 comp.sys.dec:556
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!pasteur!ames!hao!gatech!bloom-beacon!mit-eddie!jbs
From: jbs@eddie.MIT.EDU (Jeff Siegal)
Newsgroups: comp.unix.wizards,comp.sys.dec
Subject: Re: bug report etiquette
Message-ID: <8308@eddie.MIT.EDU>
Date: 27 Feb 88 17:42:08 GMT
References: <2323@umd5.umd.edu> <10102@ulysses.homer.nj.att.com> <2338@umd5.umd.edu> <10110@ulysses.homer.nj.att.com> <2346@umd5.umd.edu> <3261@bloom-beacon.MIT.EDU>
Reply-To: jbs@eddie.MIT.EDU (Jeff Siegal)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 17
Cc: nessus@athena.mit.edu


In article <3261@bloom-beacon.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
>The TK50 performs very very very slow and unreliably if it
>doesn't get to stream.  The block device is double buffered, while the
>raw device is not.  If the raw device is used [...], the
>tape drive doesn't stream.  If the block device is used [...],
>the tape drive does stream, [...].

In addition to the buffering, the block device forces an abysmally
small block size (as Chris pointed out).  This is a conventional way
to make streaming tape drives stream (by reducing the tape data rate
and density), and also a great way to cripple a tape subsystem.  A
much better way to drive such devices is with raw, asynchronous I/O.
Oh, Unix doesn't do that?  Hmm, I thought there was this other
operating system for VAX's, but I can't seem to remember the name
right now... 

Jeff Siegal